Direct comparison
SAM vs BAM vs CRAM Compared
SAM, BAM, and CRAM compared: file-size differences, when CRAM’s reference dependency is worth it, and samtools view commands to convert between them.
Written and maintained by CASRAI Editorial Board
Last updated
Ask CASRAI · included with Regulatory Radar
Ask about SAM vs BAM vs CRAM Compared
Ask CASRAI answers research-administration questions and cites the passages behind every claim — and says so when the corpus does not cover something, instead of guessing. It comes with a Regulatory Radar subscription at $29 a month, alongside the daily digest of regulatory changes and the dashboard of what changed.
150 questions a day, on this site, over the API, or inside your own tools through the CASRAI MCP server.
Everything CASRAI publishes — this page, the dictionary, the guides and the news — stays free to read, with no account and no card.
How do SAM, BAM, CRAM compare side by side?
The table below compares SAM, BAM, CRAM across 11 procurement-relevant dimensions, from encoding through lossless by default?.
Side-by-side comparison
| Dimension | SAM | BAM | CRAM |
|---|---|---|---|
| Encoding | Plain text, tab-delimited | Binary, BGZF-compressed (block gzip) | Binary, reference-based compression with per-field codecs |
| Human-readable | Yes — directly greppable/diffable | No — requires samtools/htslib to view | No — requires samtools/htslib AND the matching reference to view |
| Self-contained (no external file needed to read it) | Yes | Yes | No — needs the exact reference FASTA used to compress it |
| Typical size vs. equivalent BAM | Several-fold larger than BAM (uncompressed text) | Baseline | Roughly 35–70% smaller, platform-dependent (htslib benchmarks: ~66% smaller for Illumina NovaSeq, ~45% for HiSeq 2500, ~73% for PacBio Revio, ~37% for Oxford Nanopore, at default settings) |
| Indexed random access | No (not normally indexed) | Yes — .bai index on coordinate-sorted files | Yes — .crai index on coordinate-sorted files |
| Risk if the reference becomes unavailable or ambiguous | Not applicable — no reference dependency | Not applicable — sequence is stored directly | File becomes undecodable — not degraded, unreadable — unless the exact reference (matching contig MD5s) is separately archived and retrievable |
| Best fit | Debugging a pipeline, inspecting a small slice of records, or a transient stream between tools | The default working/interchange format — active analysis, sharing between labs, any workflow needing self-contained safety | Long-term archival storage at scale, where the reference (a standard build like GRCh38/T2T-CHM13, checksummed and durably hosted) is guaranteed stable |
| Convert with samtools view | samtools view -b -o aln.bam aln.sam (SAM to BAM) | samtools view -C -T ref.fa -o aln.cram aln.bam (BAM to CRAM, -T mandatory) | samtools view -b -T ref.fa -o aln.bam aln.cram (CRAM to BAM, same reference required) |
| Governing specification | SAM/BAM specification, samtools.github.io/hts-specs | Same SAM/BAM specification (BAM is its defined binary form) | CRAM v3.x specification (current); v2.1 is an obsolete predecessor, both at samtools.github.io/hts-specs |
| Common file/index extensions | .sam (no standard index) | .bam, indexed as .bam.bai | .cram, indexed as .cram.crai |
| Lossless by default? | Yes — no compression applied at all | Yes | Yes by default; optional lossy modes (e.g. quality-score binning) exist but must be explicitly enabled |
Common questions
Common questions about SAM vs BAM vs CRAM
Do I need the reference genome to open a CRAM file?
+
Yes, and it must be the exact reference used at compression time — matched contig-by-contig via MD5 checksum. Without it, samtools and other htslib-based tools cannot decode the file at all; this is not a slowdown, it is a hard failure. Keep the reference FASTA (and ideally its checksums) archived alongside any CRAM file you intend to read again later.
How much smaller is CRAM than BAM in practice?
+
It depends heavily on sequencing platform and data type. htslib’s published benchmarks on 10 million alignments show CRAM 3.1 files roughly 35–73% smaller than the equivalent default BAM — the largest gains on Illumina short-read and PacBio long-read data, a narrower gain (~37%) on Oxford Nanopore data where quality-score entropy compresses less well. There is no single universal ratio; test on your own data if the number matters for a budget decision.
Is CRAM ever the wrong choice even for archival storage?
+
Yes, when the reference used for alignment is non-standard, unpublished, a lab-specific assembly, or otherwise not guaranteed to be durably retrievable years later. If the reference could become unavailable, get revised without a stable version identifier, or was simply never archived, CRAM trades a real storage saving for a real risk of total data loss. BAM’s self-containedness is worth the extra disk space in exactly that situation.
Can I convert directly from SAM to CRAM, skipping BAM?
+
Yes — samtools view -C -T ref.fa -o aln.cram aln.sam works directly; BAM is not a required intermediate step, it is just the historically dominant intermediate format most pipelines still emit by default.
Does converting to CRAM lose any information?
+
Not by default — samtools’ default CRAM profile is lossless for sequence and alignment data. CRAM does support optional lossy modes (e.g. quality-score binning) for further size reduction, but those are opt-in, not the default, and should only be used when the downstream analysis is known to tolerate reduced quality-score precision.
Which format should a new pipeline standardize on?
+
BAM for anything actively read/written or shared outside a controlled environment where the reference might not travel with the file; CRAM for long-term, high-volume archival where the reference is a well-known, checksummed, durably hosted build. Most production pipelines keep BAM during active analysis and convert to CRAM only at the archival step.
