BAM vs CRAM: Should You Convert Your Genome Files?

Short answer

Convert only if storage is a real problem and you know, and will keep, the exact reference FASTA your BAM was aligned to. CRAM stores reads as differences from that reference, so without it the file may be unreadable. Use lossless settings (the samtools default), check that record counts match, and keep the original BAM until the CRAM is verified and backed up.

What a BAM file is

If you've had your whole genome sequenced, the BAM is usually the biggest file you can download. It holds your sequencing reads, each aligned to a position on a reference genome, along with base quality scores and other tags. In the SAM specification, BAM is the binary form of SAM, compressed in BGZF, a block format built on gzip. The blocks are what let an index file (.bai) jump straight to a region without reading everything.

A BAM is self-contained. You don't need any other file to read the bases back out of it. That matters more than it sounds.

What a CRAM file is

CRAM holds the same kind of aligned-read data, compressed differently. The CRAM specification (currently covering versions 3.0 and 3.1) lists its objectives as "significantly better lossless compression than BAM", full compatibility with BAM, an easy transition from BAM, and support for "controlled loss" of data for people who choose it.

The main trick is reference-based compression. Most of your reads match the reference genome almost exactly, so instead of storing every base, CRAM stores where a read sits and how it differs from the reference. The bases are rebuilt from the reference when the file is read.

How much space that saves depends on the data, how it's sorted and the settings used. The htslib documentation notes, for instance, that CRAM is less efficient for unsorted data. This article doesn't quote a typical ratio. The reliable way to find out is to convert a copy of your own file and compare.

The catch: you must keep the exact reference

Because the bases are stored as differences, a CRAM is only readable alongside the reference FASTA it was made with. The htslib CRAM guide is blunt: "The reference must be available at all times. Losing it may be equivalent to losing all your read sequences."

"Exact" means the same sequences, not merely the same build name. "GRCh38" is distributed in several flavours: with or without alternate contigs and decoy sequences, and with chr1 or 1 style names. CRAM records an MD5 checksum (the M5 tag) for each reference sequence in the header. If you supply the wrong reference, htslib usually stops with an MD5 mismatch error instead of silently producing wrong bases.

Don't count on automatic downloads either. According to the samtools manual, versions 1.21 and earlier fetched missing references from the EBI's CRAM reference server by default. That default has since been removed, so a modern install will simply fail if it can't find the reference locally.

To see which reference your BAM was aligned to, list the sequence lines in its header:

samtools view -H sample.bam | grep '^@SQ' | head

Each @SQ line gives a sequence name (SN) and length (LN), and may include an M5 checksum, a UR path to the FASTA and an AS assembly name. If your provider didn't say which FASTA they used, ask before converting. The VCF header guide explains how chromosome lengths reveal GRCh37 versus GRCh38.

Lossless versus lossy CRAM

By default, samtools writes lossless CRAM: reads, bases, quality scores and tags all survive the round trip. There are two technical exceptions. The MD and NM tags are normally recalculated on decoding rather than stored (store_md and store_nm are off by default), and samtools adds a @PG line to the header recording the command. The data is the same, but the bytes won't be.

Lossy choices are opt-in. In samtools, the clearest one is lossy_names=1, which drops read names and generates new ones when the file is decoded. The CRAM format also allows tools to discard or coarsen other data, such as quality scores. For a personal archive, the sensible default is stay lossless: storage is cheaper than data you can never get back.

samtools also offers compression profiles: fast, normal (the default), small and archive. They change how hard the compressor works and which codecs it uses, trading speed for size. They don't decide what data is kept.

Will your tools read CRAM?

Anything built on htslib (samtools, bcftools and many pipelines) reads CRAM natively. Other software varies, and some online services only accept BAM or FASTQ uploads. Every program that reads your CRAM also needs access to the matching reference. Before converting the only copy you have, check the documentation of each tool or service you plan to use.

How to convert BAM to CRAM with samtools

This needs a terminal with samtools installed (Homebrew on macOS, Bioconda on Linux, or Windows Subsystem for Linux on Windows). The command is the example from the samtools view manual:

# 1. Index the reference (samtools will also do this for you if the .fai is missing)
samtools faidx reference.fa

# 2. Convert: -C = CRAM output, -T = reference FASTA, -o = output file
samtools view -C -T reference.fa -o sample.cram sample.bam

# 3. Index the CRAM for region lookups (creates sample.cram.crai)
samtools index sample.cram

Add -@ 4 to the view command to use extra threads for compression. Going back to BAM is the same command with -b instead of -C:

samtools view -b -T reference.fa -o roundtrip.bam sample.cram

Verify before you delete anything

Treat a conversion as unfinished until you've checked it:

Check the file is complete. samtools quickcheck -v sample.cram checks the header and the end-of-file marker. Its manual is clear that it will not detect corruption in the middle of a file, so it's only a first check.
Compare record counts. Run samtools view -c sample.bam and samtools view -c -T reference.fa sample.cram. The two numbers must match. Decoding every record also exercises the reference.
Don't expect matching checksums between the BAM and a round-tripped BAM. The @PG header lines and recalculated tags make the files differ byte for byte even when no data was lost.
Record checksums for the new set: the CRAM, the CRAI and the reference FASTA. Our checksum guide shows how.

The ways this goes wrong

The reference FASTA is deleted, lost or stored only on the same drive as the CRAM.
A "GRCh38" file is used that isn't the exact sequence set the BAM was aligned to.
The original BAM is deleted before counts are compared and backups exist.
A tool or service you rely on turns out not to accept CRAM.

So should you convert?

Keep the BAM if you have the space, if the tools or services you use want BAM, or if you aren't sure which reference was used. Consider CRAM if storage is a real constraint, you know the exact reference, and you'll store that FASTA (and its checksum) everywhere the CRAM goes. In either case, keep the original download until the CRAM is verified and backed up in at least two places. The genome storage guide covers a backup plan.

Not sure what a file actually is? The file inspector recognises BAM and CRAM locally in your browser without uploading them. It identifies them rather than parsing their contents.

And whichever format you keep, file formats don't change what your data means. Anything medically significant in it should be reviewed by a clinician or genetic counselor and confirmed by clinical testing.

Common questions

Can I open a CRAM if I've lost the reference?

Usually not for the bases. The htslib documentation warns that losing the reference may be equivalent to losing all your read sequences. The exception is a CRAM written with embedded reference data (the samtools embed_ref option), which is larger but self-contained.

Is converting BAM to CRAM lossless?

With samtools defaults, yes: reads, bases, qualities and tags are kept. Lossy options such as lossy_names have to be turned on deliberately. MD/NM tags are recalculated on decoding, and a @PG header line is added, so files won't be byte-identical.

Which reference FASTA do I need?

The exact one used to align your BAM. Check the @SQ lines in the BAM header (samtools view -H) for names, lengths and M5 checksums, and ask your provider if it isn't documented.

Will CRAM work with online analysis services?

Some accept it, and some only take BAM, FASTQ or VCF. Check each service's upload requirements before deleting a BAM.

How much smaller is CRAM than BAM?

It depends on your data and settings, so this article doesn't quote a general figure. Convert a copy and compare the sizes yourself.

Keep going

StorageThe genome storage and backup guide Raw dataWhat the Header of Your VCF File Tells You ToolIdentify a genome file locally in your browser

Sources

Checked in October 2026 against the CRAM v3.1 and SAM v1 specifications (samtools/hts-specs), the samtools and samtools-view manuals for release 1.24 (option names, defaults, the EBI reference default change), the samtools quickcheck manual, and the htslib CRAM and reference-sequence guides. Left out: any CRAM-versus-BAM compression ratio, because no primary source gives a figure that applies to consumer genomes; named third-party viewers or services, because their CRAM support couldn't be confirmed from official pages; and which reference any particular provider uses.

Educational content, not medical advice. A genetic result is information, not a diagnosis; for anything medically important, talk to a qualified clinician or genetic counselor. Some outbound links are affiliate links; see the disclosure.