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 · free to try
Ask about SAM vs BAM vs CRAM Compared
Ask your first 2 questions free below. Subscribers get 150 a day for $29 a month.
An AI assistant specialized in research administration. It cites the sources behind every answer, labels web answers and says when it can't answer.
Answers draw on CASRAI's guides and dictionary plus the federal and funder documents we index: Federal Register, Grants.gov, Regulations.gov and UKRI.
Works on this site and inside Claude, Cursor and the AI tools you already use.
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.
