BED vs BAM: When to Use Interval Files vs Alignment Files

By Dr. Zubair Khalid, DVM, MS, PhD · 2026-11-10

BED stores genomic intervals, while BAM stores sequencing reads aligned to a reference. Use BED when the question is where a feature lies, and use BAM when the question is which reads support that feature.

That rule sounds simple, and it is, but real pipelines mix the two formats constantly. A peak caller writes BED intervals after reading BAM alignments. A coverage tool reads BAM evidence and a BED target set. A genome browser may show BED peaks above BAM read piles. The formats are not competitors at the same layer. BED is a compact interval format. BAM is a read-level alignment format. The practical question is not which format is better in general. The question is which format carries the evidence your next step needs.

This guide explains the difference between BED and BAM, shows where each format fits among common bioinformatics file formats, gives concrete scenarios for choosing BED or BAM, and lists the mistakes that cause silent coordinate and counting errors.

Quick rule: reads or regions

Choose BED when you need a list of genomic ranges. Examples include promoter windows, blacklist regions, peak calls, capture targets, exon ranges, bins for counting, or intervals for overlap analysis.

Choose BAM when you need read-level evidence. Examples include variant calling, read counting, coverage and depth calculation, splicing analysis, duplicate marking, mapping quality filtering, or inspection of individual alignments.

Use both when the analysis needs evidence and regions together. A BAM can supply the reads. A BED can supply the regions to query, mask, count, or annotate. This combination is common in targeted sequencing, ChIP-seq, ATAC-seq, RNA-seq QC, and coverage reports.

A useful test is to ask what the next tool consumes. If the tool expects a list of regions, give it BED. If the tool expects aligned reads, give it BAM. If the tool expects both, keep the BAM as the evidence layer and the BED as the query layer.

What BED actually is

BED stands for Browser Extensible Data. It is a tab-delimited text format for genomic intervals. The first three columns are mandatory: chromosome, start, and end. Additional columns are optional and can carry a name, score, strand, thick display coordinates, color, and block structure. A BED file has no required header. Many BED files start directly with data rows.

BED is one of the interval formats read and written by pygenomics, which also handles GFF3 and VCF and implements interval operations [1]. That support matters because BED is often one piece of a larger interval workflow, not the only file in the project.

BED coordinates in plain terms

BED uses 0-based, half-open coordinates. The start is zero-based. The end is exclusive. An interval written as chr1 100 200 includes 0-based positions 100 through 199, which correspond to 1-based positions 101 through 200. The length of the interval is 200 minus 100, or 100 bases.

This coordinate rule is the source of many off-by-one errors. SAM and BAM use 1-based positions for the leftmost mapping position of a read. GTF and GFF use 1-based, inclusive coordinates. A BED interval converted to GTF without adjusting the start will shift by one base. A BED interval compared to a BAM position without accounting for the coordinate systems can include or exclude the wrong boundary base.

The half-open rule also affects overlap logic. Two BED intervals that touch end to start, such as chr1 100 200 and chr1 200 300, do not overlap. They are adjacent. An interval that ends at 200 and another that starts at 200 share a boundary but no bases. Tools that use half-open logic treat that as no overlap. Tools that use inclusive logic may treat it differently.

What BED stores and what it leaves out

BED stores intervals. It does not store reads. It does not store base qualities. It does not store mapping quality. It does not store CIGAR strings, flags, read groups, or per-base alignment evidence.

A BED file can store a name for each interval. It can store a score. It can store strand. It can store display information for a genome browser. It cannot tell you how many reads support an interval unless a separate coverage or count step has already produced that number. A BED file with a coverage column is a derived summary, not raw read evidence.

BED also has no mandatory sample metadata. A BED file named peaks.bed does not prove which sample, reference build, or peak caller produced it. Keep a sample sheet, a workflow log, and a reference build record beside the file.

Common BED variants

BED3 has chromosome, start, and end. BED6 adds name, score, and strand. BED12 adds thickStart, thickEnd, itemRgb, blockCount, blockSizes, and blockStarts. Peak callers often write narrowPeak or broadPeak files, which are BED-like formats with extra columns for signal, p-value, and q-value. These are still interval files, but they are not plain BED3.

The extra columns are not standardized across every producer. A score column may follow the UCSC BED convention, or it may hold a peak caller statistic. Read the tool documentation before treating a BED column as a universal measure. The first three columns are the stable part. Everything after that depends on the producer and the consumer.

What BAM actually is

BAM stands for Binary Alignment Map. It is the binary, compressed representation of SAM, the Sequence Alignment/Map text format. A BAM file stores sequencing reads and their alignment to a reference. It can also store unmapped reads. Each record includes the read name, flag, reference name, position, mapping quality, CIGAR string, mate information, template length, sequence, base qualities, and optional tags.

BAM is not a raw read format. FASTQ is the raw read format. BAM is what you get after aligning FASTQ reads to a reference and converting the SAM output to binary. A BAM file usually depends on a reference genome for interpretation, and CRAM, a more compressed alignment format, can depend on the reference for decoding.

From FASTQ to BAM

A typical short-read workflow starts with FASTQ files. FASTQ stores each read sequence and a per-base quality score. The aligner reads the FASTQ files and a reference FASTA, places reads on the reference, and writes SAM or BAM. The BAM is then sorted and indexed.

The reference FASTA is a separate file. FASTA stores sequences without per-base quality scores. It may hold a whole genome, a transcript set, or a protein collection. In a DNA alignment workflow, the reference FASTA is the coordinate system against which BAM positions are defined.

After alignment, BAM becomes the working format for many read-level steps. Tools can filter reads by mapping quality, remove duplicates, clip overlaps, count reads in regions, call variants, or calculate depth. Each of those operations needs information that BED does not carry.

What a BAM record carries

The SAM/BAM record has fields that matter for downstream decisions. The flag records whether a read is paired, mapped, reverse-complemented, a duplicate, or a secondary alignment. The mapping quality records confidence in the alignment. The CIGAR string records matches, insertions, deletions, clipping, and skipped regions. The read group tag can link a read to a sample, library, or sequencing lane. Optional tags can carry alignment scores, tags from other tools, and per-read metadata.

These fields are why BAM is the evidence layer for variant calling and read-level QC. A BED interval can say that a region is a candidate exon. A BAM can show reads spanning the exon junction, reads with mismatches, reads with soft clipping, and reads with low mapping quality. The BED cannot replace that evidence.

Sorting, indexing, and CRAM

Many tools require a coordinate-sorted BAM plus an index. The index is usually a .bai file, or a .csi file for larger references or specific use cases. The index enables random access to a genomic region without reading the entire file. Sorting and indexing are separate steps. A BAM can be sorted but not indexed. A BAM can have an old index that no longer matches the current file. Both situations cause failures or wrong results.

Not every tool requires sorted input. PanDepth accepts sorted or unsorted BAM and CRAM files for coverage calculation [2]. That flexibility is useful for quick QC. It does not make sorting optional everywhere. Check the requirement of each tool before assuming that an unsorted BAM will work.

CRAM is an alignment format that compresses reads relative to a reference. It can reduce storage compared with BAM, but it needs the correct reference for decoding. A CRAM without the matching reference may fail to open or may produce wrong sequences. Keep the reference FASTA and its checksum with the CRAM.

BED vs BAM at a glance

The table captures the main difference between BED and BAM. BED is a compact description of regions. BAM is a record of reads mapped to a reference. The formats answer different questions, and the best choice follows the question.

How to choose: the criteria that decide real workflows

Does the task need read-level evidence?

If the task needs read-level evidence, use BAM. Variant calling needs reads, base qualities, mapping qualities, and alignment context. Read counting needs reads that overlap regions. Splicing analysis needs CIGAR operations and junction evidence. Duplicate marking needs read pairs and alignment positions. Coverage and depth calculation needs aligned reads or a precomputed coverage track.

BED cannot supply that evidence. A BED interval can define a candidate region, but it cannot prove that any read supports the region. A BED file with a count column is a summary produced by a previous BAM-based step. The summary is useful, but it is not a substitute for the alignment file when the next step needs read-level details.

Does the task need only interval logic?

If the task needs interval logic, use BED. Interval logic includes overlap, intersection, subtraction, merge, complement, flanking regions, and region annotation. These operations ask where features are relative to one another. They do not need read sequences or alignment records.

BED is also the natural format for genome browser tracks showing peaks, target regions, or annotations. A BED track is compact and easy to share. A BAM track is better when a viewer needs to inspect individual reads, mismatches, and splice junctions.

Is coverage or depth the goal?

Coverage and depth are properties of alignments. A BED file alone cannot compute read depth. A BED file can define the regions for which depth should be calculated. The evidence still comes from BAM or CRAM.

PanDepth calculates coverage from BAM or CRAM alignments and accepts BED, GTF, GFF, or a fixed window as the region definition [2]. That design shows the correct division of labor. The alignment file supplies the reads. The interval file supplies the target regions. A coverage workflow can therefore pass a BAM as evidence and a BED as the target set to PanDepth [2].

Be careful with the word coverage. In some tools, coverage means the fraction of a BED interval covered by at least one read. In other tools, coverage means sequencing depth at each base. These are different summaries. Read the tool documentation and the output columns before comparing results across tools.

How much storage and I/O can the workflow afford?

BAM is usually much larger than BED because it stores every read, base, quality score, and alignment record. BED stores only intervals and optional interval-level fields. For a project with many samples, BAM storage and I/O can dominate the compute budget. CRAM can reduce alignment storage, but it adds a reference dependency.

The choice is not only about disk size. It is also about how often the file is read. A BED target set may be read thousands of times by many tools. A BAM may be read once for alignment QC and then again for variant calling. Keep the BAM when the evidence is needed repeatedly. Convert to BED when only the interval summary is needed.

Does the workflow need metadata and reproducibility?

BAM carries a header with reference sequences, read groups, and processing records. Those fields help trace a sample, a reference build, and the alignment pipeline. BED has no required header and usually no read-group metadata. BED provenance depends on file naming, workflow logs, and sample sheets.

This difference matters in production. A BAM header can record the reference sequence names and lengths. A BED file with chr1 may be from one reference build, while another BED file with chr1 may be from a different build. Without a build record, the interval coordinates are ambiguous. Store the reference build with every BED and BAM.

Which tools will consume the file?

Tool requirements decide many format choices. Some tools accept BAM directly for interval operations. Some tools require BED. Some tools accept both but treat them differently. pygenomics supports BAM and BED in the same package and exposes interval operations through an API and command line interface [1]. That kind of library reduces the need for ad hoc parsing, but it does not remove the need to know which input type a step expects.

When a tool accepts both BED and BAM, check what it does with each. A tool that accepts BAM may count reads. A tool that accepts BED may count intervals or bases. The same command name can produce different summaries depending on input type.

When to use BED

Use BED for region definitions. Promoter windows, enhancer windows, exon ranges, untranslated regions, blacklist regions, and capture targets are all interval lists. BED keeps them compact and easy to intersect with other interval sets.

Use BED for peak calls and thresholded regions. A peak caller typically reads BAM alignments and writes BED or a BED-like peak file. Downstream steps then overlap peaks with annotations, compare peak sets between samples, or count reads in peaks.

Use BED for interval set operations. Merge overlapping intervals, subtract blacklist regions, find overlaps between two peak sets, or build flanking regions around a feature set. These operations need coordinates, not reads.

Use BED for genome browser tracks. A BED track can show peaks, target regions, or gene annotations. It is lightweight and easy to share. Use BAM in the browser when the goal is to inspect read alignments.

Use BED as the target set for coverage tools. PanDepth accepts BED, GTF, GFF, or a window size as the region definition and calculates coverage from BAM or CRAM [2]. The BED defines where to look. The BAM supplies the reads.

Use BED when privacy or file size limits matter. A BED file with intervals only does not contain read sequences or base qualities. That reduces the risk of exposing raw sequence data, although interval coordinates can still be sensitive in some study designs.

When to use BAM

Use BAM when the analysis needs reads. Variant calling, indel realignment, base quality score recalibration, duplicate marking, and read filtering all need alignment records. BED cannot supply those records.

Use BAM for read counting in regions. Counting reads in peaks, exons, or target intervals requires the reads and the intervals. The BAM supplies the reads. The BED or GTF supplies the intervals. The counting tool applies an overlap rule.

Use BAM for coverage and depth. Depth at each base, breadth of coverage over a target, and uniformity metrics all depend on aligned reads. PanDepth is built for coverage calculation from BAM and CRAM files and accepts interval files or a window size for the target regions [2].

Use BAM for splicing and junction analysis. CIGAR strings record skipped regions and insertions. BED intervals can define candidate junctions, but the BAM records show which reads support them.

Use BAM for alignment QC. Mapping rate, duplicate rate, insert size, mapping quality distribution, and read length distribution are read-level summaries. They require BAM or a tool that reads BAM.

Use BAM when the file must carry sample and reference metadata. The BAM header can record reference sequences, read groups, and processing steps. That metadata supports reproducible analysis and troubleshooting.

When to use both

Many workflows need both formats. The BAM is the evidence layer. The BED is the query layer. The workflow reads the BAM, produces or consumes a BED, and then may return to the BAM for read-level checks.

A peak calling workflow is a clear example. The aligner writes BAM. The peak caller reads BAM and writes BED peaks. The downstream annotation step reads BED peaks and a gene annotation. The counting step reads BAM reads and BED peaks. The genome browser shows BED peaks above BAM reads.

A targeted sequencing workflow is another example. The capture kit defines BED targets. The aligner writes BAM. The coverage tool reads BAM and BED targets. The variant caller reads BAM and may restrict to BED targets. The report shows BED target intervals and BAM-based depth.

A RNA-seq QC workflow may use BAM and BED or GTF. The BAM supplies reads and splice junctions. The annotation supplies exon and transcript intervals. A BED of custom regions can define a targeted count set. The BAM remains the evidence.

pygenomics reads and writes BAM and BED, which makes it useful for small format conversions and set operations [1]. The important point is not the specific library. The point is that format conversion is a normal part of the workflow, and the evidence should not be discarded without a reason.

Worked scenarios

Scenario 1: ChIP-seq peak calling and annotation

Start with FASTQ reads and a reference FASTA. Align the reads and write BAM. Sort and index the BAM. Run a peak caller that reads the BAM and writes BED or narrowPeak intervals. Annotate the BED peaks with gene models. Count reads in the BED peaks using the BAM.

The BAM is required for alignment, peak calling, and read counting. The BED is required for peak storage, overlap with annotations, and browser display. Converting the BAM to BED too early would discard read-level evidence needed by the peak caller. Keeping only the BED after peak calling would discard the evidence needed for read-count QC.

Scenario 2: Targeted coverage report

Start with a BED file of capture targets. Align reads to the reference and write BAM. Sort and index the BAM if the coverage tool requires it. Run a coverage tool with the BAM as evidence and the BED as the target set. PanDepth accepts BAM or CRAM alignments and BED, GTF, GFF, or a window size for the regions [2].

The BED alone cannot produce depth. It defines the target intervals. The BAM alone can produce genome-wide depth, but it does not know which intervals are the capture targets. The two files are complementary.

Scenario 3: Variant calling restricted to a panel

Use a BED file to define the panel regions. Align reads to the reference and write BAM. Run the variant caller on the BAM and restrict analysis to the BED regions. The BAM supplies read evidence, base qualities, mapping qualities, and alignment context. The BED restricts the search space.

A BED-only variant workflow is not possible because BED has no reads. A BAM-only workflow can call variants genome-wide but may waste time outside the panel. The BED improves focus without replacing the evidence.

Scenario 4: Comparing two peak sets

Take two BED peak files from two samples. Merge each file, intersect the two sets, and subtract one set from the other. The result is a new BED file of shared, sample-specific, or non-overlapping regions.

No BAM is needed for the set comparison itself. Keep the original BAM files if the next step requires read counts or motif analysis that depends on read-level evidence. The BED set comparison answers an interval question. The BAM answers a read question.

Scenario 5: Genome browser review

Load a BED track to see peak locations. Load a BAM track to inspect individual reads, mismatches, and splice junctions. Use the BED track for the overview. Use the BAM track for read-level review.

A browser can display both. The BED track is compact and fast. The BAM track is heavier but shows the evidence. Choose the track type that matches the question being asked at that moment.

Scenario 6: Counting reads in custom regions

Define custom regions in BED. Align reads and write BAM. Use a counting tool that accepts BAM and BED. Decide the overlap rule before counting. A read that overlaps two regions may be counted twice. A read pair may be counted as one fragment or two reads. A multimapping read may be counted or excluded.

The BED defines the regions. The BAM supplies the reads. The counting tool applies the rule. The same BAM and BED can produce different counts under different rules, so record the rule in the workflow.

Where FASTQ and FASTA fit

FASTQ and FASTA are not BED or BAM. They sit at different layers of the workflow. FASTQ stores raw sequencing reads with per-base quality scores. FASTA stores sequences without per-base quality scores. A reference genome is usually FASTA. A transcript set is often FASTA. A protein set is often FASTA.

The common pipeline order is FASTQ to BAM to BED. FASTQ enters the aligner. The aligner reads a reference FASTA. The aligner writes SAM or BAM. Downstream interval analysis writes BED. The BED is a derived summary of regions, not a replacement for the raw reads or the alignments.

The FASTQ vs FASTA distinction is separate from the BED vs BAM distinction. FASTQ and FASTA are sequence file formats. BED and BAM are interval and alignment formats. A project may need all four. Keep the raw FASTQ if reanalysis is possible. Keep the BAM if read-level evidence is needed. Keep the BED if interval summaries are reused. Keep the reference FASTA with its build and checksum.

Common Mistakes and Limitations

Treating BED starts as 1-based

BED starts are 0-based. SAM positions are 1-based. GTF and GFF coordinates are 1-based and inclusive. Converting between them without adjusting the start shifts intervals by one base. A one-base shift can move a peak off a transcription start site or exclude the first base of a target interval. Check the coordinate convention before every conversion.

Confusing BED with GFF or GTF

BED, GFF, and GTF are all interval formats, but they use different columns and coordinate rules. GFF and GTF are 1-based and inclusive. BED is 0-based and half-open. A tool that autodetects format may guess wrong when a file has unusual columns. Convert explicitly and validate the first few intervals against a known feature.

Assuming every BAM is sorted and indexed

Many region-based tools require a coordinate-sorted BAM and a matching index. A BAM can be sorted but not indexed. An index can be stale after a file is modified. Some tools accept unsorted BAM, and PanDepth accepts sorted or unsorted BAM and CRAM for coverage [2]. That flexibility is tool-specific. Check the requirement before running a batch.

Using BED to claim read support

A BED interval does not prove that reads support it. A peak caller may have produced the interval from BAM evidence, but the BED file alone does not carry that evidence. If a review or downstream step needs read support, keep the BAM and inspect the reads. Do not treat an interval name or score as proof of read-level coverage.

Forgetting the overlap rule

Counting reads in BED intervals depends on the overlap rule. Does a read need to overlap one base, fall entirely inside the interval, or span the interval? Are paired reads counted as fragments or as two reads? Are multimapping reads included? Are duplicates removed? The same BAM and BED can produce different counts under different rules. Record the rule and the tool version.

Treating a BED score as a universal metric

The BED score column is not standardized across every producer. A score may be a UCSC display score, a peak caller statistic, or a custom value. Do not compare scores across tools without checking their definitions. The first three columns are the stable part of BED. The optional columns need documentation.

Assuming BED carries sample metadata

BED has no required sample metadata. A file named sampleA_peaks.bed does not prove the sample, reference build, or peak caller. Keep a sample sheet and a workflow log. Put the reference build in the file name or in a companion metadata file.

Using BAM when BED is enough

BAM is heavy. If the task only needs interval overlaps, carrying BAM through every step wastes storage and I/O. Convert to BED after the read-level step when the remaining analysis is interval-only. Keep the BAM archived if the evidence may be needed later.

Using BED when BAM is required

BED cannot call variants, calculate base-level depth, or inspect splicing. If the next step needs reads, BED will not work. A BED file with a depth column is a summary, not an alignment file. Use BAM or CRAM for read-level evidence.

Ignoring CRAM reference requirements

CRAM can reduce alignment storage, but it needs the correct reference for decoding. A CRAM without the matching FASTA may fail or produce wrong sequence. Keep the reference and its checksum with the CRAM. If a tool does not support CRAM, convert to BAM before the step.

Forgetting compression and indexing for BED

Large BED files are often compressed with bgzip and indexed with tabix for random access. A plain gzip file may not support region queries. Check whether the tool expects plain BED, bgzipped BED, or a tabix index. The file extension alone does not guarantee the compression and index are correct.

Frequently Asked Questions

Is BED better than BAM?

No. BED is better for interval-only tasks and BAM is better for read-level evidence. They solve different problems.

Can I convert a BAM file to BED?

Yes. Tools such as bedtools bamtobed convert aligned reads to intervals. The result keeps read coordinates but drops most alignment metadata, including mapping quality, CIGAR details, and per-base qualities.

Can I convert a BED file to BAM?

Not directly in a meaningful way. BED lacks reads, sequences, qualities, and alignment records. You can use BED to filter or annotate a BAM, but BED cannot replace the alignment evidence.

Do I need an index to use a BAM with interval tools?

Often yes. Many tools require a coordinate-sorted BAM plus a .bai or .csi index for random access. Some tools accept unsorted BAM, so check the requirement for each step.

Is BAM the same as FASTA?

No. FASTA stores sequences, while BAM stores read alignments to a reference. A BAM often needs the reference FASTA for CRAM decoding, variant calling, or alignment inspection.

Which format should I load in a genome browser?

Use BED or a coverage track for compact region display and BAM for read alignments. BED is usually better for peaks and target regions. BAM is better for inspecting individual reads.

Further Reading

• The association between mechanical ventilator compatible bed occupancy and mortality risk in intensive care patients with COVID-19: a national retrospective cohort study.
• Pre-Bed Casein Protein Supplementation Does Not Enhance Acute Functional Recovery in Physically Active Males and Females When Exercise is Performed in the Morning.
• Effect of large-scale installation of deltamethrin-impregnated screens and curtains in Bam, a major focus of anthroponotic cutaneous leishmaniasis in Iran.

Sources

1. Pygenomics: manipulating genomic intervals and data files in Python.
2. PanDepth, an ultrafast and efficient genomic tool for coverage calculation.