VCF vs BCF: Which Variant Call Format Should You Use

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

VCF is a plain-text, line-per-variant format you can read, diff, and grep, and BCF is the same data model encoded in binary and compressed so that htslib-based tools can parse it quickly. The rule of thumb is simple: use VCF when a human, a web portal, or a legacy tool has to read the file, and move to BCF when the file is large, you query it repeatedly, or you want to save disk without giving up random access.

That rule gets you 90 percent of the way. The remaining 10 percent is where projects get into trouble, because the difference between VCF and BCF is not really a difference in content. It is a difference in encoding, container, and ecosystem support, and each of those has consequences for storage, compute time, and reproducibility.

The One-Sentence Difference

VCF stores variant records as tab-delimited text lines under a structured header, and BCF stores the identical header and records as typed binary values inside BGZF-compressed blocks.

Everything else follows from that sentence. Text is portable and inspectable but expensive to parse. Binary is compact and fast but opaque. Both can hold the same fields, the same genotypes, and the same annotations, and converting between them with bcftools is lossless in normal use.

What VCF Actually Is

The Variant Call Format is a text specification for describing positions where a sample or a cohort differs from a reference genome. The current specification is maintained by the Global Alliance for Genomics and Health, and it is the lingua franca of variant calling, annotation, and clinical reporting.

A VCF file has two parts. The header is a set of lines that begin with a single #. Meta-information lines begin with ## and declare the file format version, the reference build, the contig list, and, critically, the definition of every INFO, FORMAT, FILTER, and ALT identifier used later in the file. The final header line begins with a single # and defines the columns, ending with the sample names.

The body is one line per variant record with eight mandatory fields followed by optional ones:

1. CHROM, the contig name.
2. POS, the 1-based position on that contig.
3. ID, a semicolon-free identifier such as an rs number, or . when absent.
4. REF, the reference allele.
5. ALT, a comma-separated list of alternate alleles.
6. QUAL, a phred-scaled quality score for the assertion that a variant exists at that site.
7. FILTER, a label such as PASS or a named failure mode, which must be declared in the header.
8. INFO, a list of key-value annotations for the site.

If genotypes are present, a ninth column named FORMAT declares the per-sample fields, and every subsequent column holds one sample's values in that order. The most important FORMAT field is GT, the genotype, written as allele indices such as 0/1 for a heterozygous call on a diploid sample or 1|1 for a phased homozygous alternate. Other common FORMAT fields include DP for read depth, AD for allele depths, GQ for genotype quality, and PL or GL for genotype likelihoods.

Three practical properties of VCF matter for choosing it. It is human readable, so a reviewer can open a region and see exactly what was called. It is streamable, so ordinary Unix text tools work on it. And it is verbose, because every record repeats full allele strings and every annotation key, and every genotype in a cohort of thousands of samples adds another tab-delimited column to every line.

VCF files are almost always distributed gzipped. For indexing to work, that gzip stream must be BGZF, a block-gzip variant that stores compressed blocks with virtual offsets. A .vcf.gz indexed with tabix or bcftools answers regional queries without decompressing the whole file.

What BCF Actually Is

BCF stands for Binary Call Format. It is defined alongside VCF in the htslib project and shares the VCF data model exactly: the same header semantics, the same INFO, FORMAT, and FILTER identifiers, the same genotype encoding. What changes is the physical representation.

In BCF, the header is stored as a length-prefixed text block, then the records are written as binary structures. Each record encodes its chromosome as an integer index into the contig dictionary from the header, its position as a typed integer, and its alleles through a per-record dictionary so that REF and ALT strings appear once and individual genotypes reference them by index. INFO and FORMAT values are typed as integers, floats, or characters rather than as text, which is the core efficiency gain: a reader does not have to convert the string "0.998" into a double for every sample at every site.

BCF is always compressed with BGZF, and it must be indexed before regional access. BCF indexes use the CSI format, which supports contigs longer than the roughly 512 Mb limit of the older tabix .tbi index and scales to reference-grade assemblies.

The consequences of the binary encoding are concrete. A BCF file cannot be opened meaningfully in a text editor, though a tolerant editor will show you a corrupted mess of characters instead of refusing outright, which is worse. It cannot be piped into grep or awk. It must be read through a library that understands the format, such as htslib, pysam, cyvcf2, vcfpp, or bcftools itself.

The trade is that those libraries read BCF quickly, because there is no per-field text parsing. Tools built on htslib expose both formats through the same API, which is why the choice is often reversible at any point in a pipeline. cyvcf2, for example, is a Python library for fast parsing and querying of both VCF and BCF files, and it presents the two as interchangeable inputs [1]. The same holds for the vcfpp C++ API, which wraps htslib in a single portable header and is used to build high-performance R packages [2].

Side-by-Side Comparison

The Size Question: What the Benchmarks Actually Show

The intuition that BCF is dramatically smaller than VCF is only partly true, and the published numbers are worth looking at directly.

A benchmark on 1000 Genomes Phase 3 data compared four representations of the same call set. The plain VCF came to 14.0 Gb, the BCF came to 12.3 Gb, a genotype-only representation called BGT came to 3.5 Gb, and the array-oriented SeqArray format came to 2.6 Gb [3]. Two things follow from that table. First, BCF did save space, roughly 12 percent against that VCF. Second, BCF is nowhere near the compression ceiling, since SeqArray stored the same data in about one fifth of the VCF footprint and less than a quarter of the BCF footprint [3].

Specialized VCF compressors push further. GSC, a lossless compressor built specifically for genotype-heavy VCF files, reported compression ratios 26.9 percent to 82.4 percent higher than the GBC and GTC tools across open-source datasets, and 1.5x to 6.5x greater than general-purpose compressors including gzip, zstd, and BCFtools output [4]. VCFShark reported compression up to an order of magnitude better than the two de facto standards, gzipped VCF and BCF, with the largest advantage on files carrying large amounts of genotype data, processing at up to 100 MB/s and staying under 30 GB of memory [5].

The honest reading is this. Convert VCF to BCF and you get a real but modest size reduction plus a solid speed gain. If disk is your binding constraint and you can accept slower decompression or a nonstandard reader, purpose-built compressors and array formats beat BCF by a wide margin. The GSC authors are explicit that their high ratios come with longer decompression times, reported as 1.2x to 2x slower than GBC while 1.1x to 1.4x faster than GTC [4]. Compression ratio, decompression speed, and tool compatibility form a triangle, and BCF sits near the middle of it.

The Speed Question: Parsing, Filtering, and Parallelism

Speed arguments for BCF usually conflate three different costs: parsing a record, filtering a record, and compressing the output.

Parsing favors BCF. The SeqArray benchmark found that reading genotypes through the SeqArray package was two to three times faster than the htslib C library working on BCF files, which says something useful: even the binary path has overhead, and array layouts beat it [3]. Against text VCF the gap is wider still, since text parsing requires repeated string-to-number conversion.

Filtering is where format choice interacts with tooling. vembrane consolidates VCF and BCF filtering into Python expressions that operate on the file specification and on annotation extensions from VEP and SnpEff, and it achieves its speed by using pysam with lazy evaluation [6]. Because pysam sits on htslib, vembrane reads both formats, so the filter expression is identical and only the I/O layer changes. The same pattern appears across the ecosystem: cyvcf2 for Python [1] and vcfpp for C++ and R [2] both treat VCF and BCF as two views of one data model.

Parallelism is a separate problem, and it is a common misconception that switching to BCF solves it. bcftools processes records on a single core, and its threaded option accelerates only compression of the output, not the work done on each variant record [7]. That is true whether the input is VCF or BCF. The pbcftools wrapper addresses this by splitting the genome into chunks, running an ordinary bcftools command on each chunk, and reassembling the results by a method suited to the output data type. On 1000 Genomes Phase 3 data, operations writing compressed VCF ran 10.8 to 21.1 times faster with 32 cores and up to 35.4 times faster with 64 cores, operations writing text ran 3.7 to 12.8 times faster, and merging 100 VCF files ran 19.2 times faster, with parallel output identical to serial output across every command tested [7].

Read that result carefully. The large gains came from splitting work across cores, not from the encoding. BCF helps you by making each core's parse cheaper. It does not create cores.

When to Use VCF

Use VCF when readability is part of the job.

1. Sharing with people outside the pipeline. A collaborator who wants to spot-check fifty variants in a region, a clinician reviewing a report, or a reviewer checking your supplementary data will all have an easier time with text. BCF requires installing a parser first.
2. Debugging a caller or an annotation step. When a call looks wrong, the fastest diagnostic is often bcftools view -H -r chr7:55019017-55211628 calls.vcf.gz and reading the raw record. Text survives that treatment.
3. Small files. A trio exome, a targeted panel, or a single-sample bacterial call set is small enough that BCF's speed advantage never repays the friction of an opaque format.
4. Text-based pipelines. If your workflow uses grep, awk, cut, sort, or comm on variant lines, or if you compute checksums on sorted records, VCF is the format that works with those tools unmodified.
5. Long-term archival where the parser may disappear. BCF is a stable, well-documented format, but a plain text file has no dependency at all beyond gzip. For records meant to outlive a software stack, text is the safer default.
6. Publication supplements and repository submissions. Many archives and journals accept VCF directly. Check the submission specification of the specific archive you use rather than assuming, and note that a compressed .vcf.gz is the usual form.

When to Use BCF

Use BCF when compute and storage dominate.

1. Large cohorts. Tens of thousands of samples across millions of sites is the regime where per-record parsing cost and per-file size both matter. BCF reduces both, and every downstream bcftools invocation benefits.
2. Repeated queries. If a cohort BCF is queried nightly by a reporting service or an annotation pipeline, the parse savings compound. This is where BCF earns its keep.
3. Intermediate files in a pipeline. Converting to BCF after calling and staying in BCF through normalization, filtering, and merging avoids repeated text parsing. A typical conversion is one command:

bcftools view -Ob -o cohort.bcf cohort.vcf.gz
bcftools index cohort.bcf

The -Ob output flag requests compressed BCF, and -Oz would request compressed VCF. To inspect any record as text:

bcftools view -Ov cohort.bcf | head -n 40

1. Genotype likelihood workflows. Likelihoods are floating-point arrays per sample per site. In VCF they are written as text lists that must be parsed on every read, while in BCF they are typed floats. Simulation tools that generate likelihoods, such as vcfgl, write both VCF/BCF and gVCF output alongside pileup, which reflects how routinely the two encodings coexist in likelihood-based analysis [8].
2. Storage on constrained infrastructure. A modest per-file reduction multiplied across hundreds of files and several pipeline stages becomes real capacity. The caveat from the benchmark section applies: if you need maximum compression, a specialized format or compressor will beat BCF [4][5][3].

Worked Scenarios

Scenario 1: A 200-sample exome study, one laboratory, one analyst. The call set is a few gigabytes compressed. Keep the working files as BCF for the repetitive filtering steps and export a .vcf.gz for the supplement and for the collaborator who reviews variants in a genome browser. Convert at the end, not in the middle.

Scenario 2: A 5,000-sample genome cohort with a query service. Store the master call set as BCF with a CSI index. Serve regional queries from the BCF. Keep one archived .vcf.gz snapshot of the finalized call set for provenance, because a text snapshot can be inspected years later without any specific library.

Scenario 3: A filter that a biologist needs to edit. vembrane expressions live in a Python-like syntax that maps directly onto VCF fields and annotation keys [6]. Because the tool reads both formats, the biologist can iterate against a small VCF excerpt and the production run can consume the full BCF without changing the expression.

Scenario 4: A pipeline that must be parallelized. Confirm first whether serial bcftools is the bottleneck. If per-record work dominates, a chunking wrapper such as pbcftools gives large speedups on the same input format, with output identical to the serial run [7]. Format conversion alone will not fix a single-core bottleneck.

Scenario 5: An R-based analysis. Tools such as vcfppR build on the vcfpp C++ API to read VCF and BCF quickly from R [2]. For very large cohorts, an array-oriented container may be a better fit than either VCF or BCF, since SeqArray stored the same 1000 Genomes call set in 2.6 Gb and read genotypes two to three times faster than htslib on BCF [3].

Scenario 6: A clinical or regulatory handoff. Deliver text. Whoever receives the file may need to open it in a validated system, attach it to a report, or read it without installing htslib. BCF is an internal optimization, not a delivery format for most external recipients.

Where VCF and BCF Sit Among Bioinformatics File Formats

It helps to place variant formats in the sequence of a project, because confusing one stage's format with another's is a common source of errors.

Raw sequencing data arrives as FASTQ, a text format that stores each read's sequence plus a per-base quality score encoded as a character. FASTA stores sequences without per-base quality scores, which is why it is used for reference genomes and protein sequences rather than for raw reads. The distinction between FASTQ and FASTA is the distinction between "data with confidence information" and "data without it."

Reads are then aligned to a reference, producing SAM, a text alignment format, or its binary equivalents BAM and CRAM. Variant calling consumes alignments and produces VCF or BCF. Each stage has a text form and a binary form, and in every case the binary form is the working format while the text form is the exchange format. The VCF and BCF pair follows exactly that pattern.

There is one variant-adjacent format worth naming: gVCF, the genomic VCF, which stores both variant sites and reference-matching blocks with per-sample depth and likelihood summaries so that cohorts can be jointly genotyped later. gVCF is a VCF dialect rather than a separate container, and tools that write BCF can generally write gVCF content in either encoding. The vcfgl simulator, for instance, emits pileup, VCF/BCF, and gVCF outputs from the same simulated reads [8].

Common Mistakes and Limitations

Editing BCF as if it were text. Opening a BCF in a text editor and saving it destroys the file. If you need to change a header line or a genotype, convert to VCF, edit, then convert back with bcftools view -Ob. Header edits that rename or remove INFO, FORMAT, or FILTER identifiers without updating their declarations will produce a file that fails validation later.

Assuming any gzip is good enough. A .vcf.gz produced by plain gzip cannot be indexed for random access. Use bgzip from htslib, or let bcftools write the compressed output, then index it. The same applies to BCF, which is always BGZF.

Forgetting the index. BCF and bgzipped VCF both need an index before regional queries work. Without one, a query for a single gene scans the entire file, and the speed advantage of BCF evaporates against a full scan of either format.

Mixing contig naming conventions. Merging a call set that uses chr1 with one that uses 1 produces files where records never join. Normalize contig names before any merge or joint genotyping step.

Believing threaded bcftools parallelizes record processing. The threaded option accelerates output compression only, not the per-record work, whether the input is VCF or BCF [7]. Measure before you assume the format is your bottleneck.

Treating BCF as maximum compression. It is a middle option. Purpose-built compressors and array formats substantially outperform it on genotype-heavy data [4][5][3].

Assuming every tool reads BCF. The htslib ecosystem does. Older custom scripts, some web portals, some visualization tools, and many one-off parsers expect text. Test the actual tool rather than the category.

Converting in the middle of a pipeline for no reason. Each conversion costs time and creates a file that must be tracked. Pick an encoding for the working phase and one for delivery, and convert once.

Lossy assumptions about annotations. Round-tripping through BCF preserves standard INFO and FORMAT values, but annotation tools that append free-text headers can produce declarations that a stricter validator rejects. Validate after conversion if the file will be shared or submitted.

Limitations. These guidelines describe general behavior of the formats and their tooling. Performance on your own data, your own storage, and your own hardware has to be measured, since file size and parse time depend heavily on sample count, variant density, and how many annotation fields you carry. The specific tools named here are examples of a broader ecosystem, not endorsements, and any individual analysis should be validated against its own requirements.

A Format Decision Framework That Survives Real Projects

The choice between VCF and BCF is easier when you separate three questions that are often asked as one. The first question is what data model you need. Both formats use the same VCF data model, so the answer is usually "either." The second question is who or what must read the file. A person, a web portal, a legacy parser, or a reviewer may need text. A bcftools pipeline, a Python service built on htslib, or an R package built on vcfpp may be perfectly happy with binary. The third question is how often the file will be read and how much it costs to store. That is where BCF usually earns its place.

A practical framework is to assign a role to each file rather than a single universal format. Call it the working role, the exchange role, and the archive role. The working role is the file that your pipeline reads and rewrites most often. For large cohorts, that file should usually be BCF with a CSI index. The exchange role is the file that leaves your control, goes to a collaborator, gets attached to a report, or gets uploaded to a repository. That file should usually be compressed VCF. The archive role is the file you keep for provenance and future inspection. A compressed VCF snapshot is often the safest archive because it depends only on gzip and a text reader, while the BCF remains the fast internal copy.

This role-based view avoids the common mistake of treating the format decision as permanent. The difference between VCF and BCF is mostly an encoding difference, and encoding can be changed at the boundaries. You do not have to run an entire project in one format just because you chose it on day one. You do have to track where conversions happen and verify that the conversions preserve the fields you care about.

What the VCF Header Promises and Why It Matters in BCF

The header is the part of a variant file that most people ignore until something breaks. In VCF, the header is visible text. In BCF, the header is still text, stored as a length-prefixed block at the start of the file, but you normally see it only through a parser or through bcftools. The semantics are the same. The header declares the file format version, the reference build, the contig list, and the definition of every INFO, FORMAT, FILTER, and ALT identifier that appears in the records.

That declaration requirement is not cosmetic. A downstream tool that sees AF in an INFO column needs to know whether AF is a float, how many values it can carry, and what it means. A tool that sees GT needs to know that GT is a genotype field with allele indices. A tool that sees a FILTER label such as LowQual needs to know that the label is defined. If the header is incomplete or inconsistent, a file can look fine in a text editor and still fail validation, annotation, or merge steps.

BCF makes this dependence more visible because the binary records use the header as a dictionary. Chromosomes are encoded as integer indices into the contig list. Alleles are encoded through per-record dictionaries. INFO and FORMAT values are typed according to their header declarations. If you edit a BCF header without updating the records, or edit records without updating the header, you can create a file that no longer parses correctly. That is why the safe editing path is to convert to VCF, edit the text with a tool that understands VCF, and then convert back to BCF. It is also why validation after conversion is not optional in shared or regulated work.

A simple header inspection step belongs at the start of any conversion:

bcftools view -h cohort.vcf.gz | head -n 40

Read the ##contig lines, the ##INFO lines, and the ##FORMAT lines. Check that the reference build matches the one used for alignment and calling. Check that contig names match the reference FASTA. Check that the sample columns are the ones you expect. These checks take a minute and prevent most of the painful failures described later.

Step by Step: A Safe Conversion Workflow From VCF to BCF and Back

A conversion workflow should be boring, repeatable, and easy to audit. The exact commands depend on your environment, but the sequence is stable.

1. Start with a validated, sorted, bgzipped VCF. If the file is plain gzip rather than BGZF, recompress it with bgzip or let bcftools write a new compressed file. A plain gzip stream cannot be indexed for random access.

1. Inspect the header and confirm the reference build, contig names, sample names, and field declarations. Use bcftools view -h and read the output rather than assuming.

1. Check that the records are sorted by coordinate. A file that is unsorted will not index correctly. If needed, sort with bcftools sort.

1. Convert to BCF with an explicit output type. The -Ob flag requests compressed BCF, and -Oz requests compressed VCF. Being explicit prevents a typo from writing the wrong container.

bcftools view -Ob -o cohort.bcf cohort.vcf.gz

1. Index the BCF. Regional queries need an index. Use bcftools so that the index matches the file.

bcftools index cohort.bcf

1. Verify that the record count and sample count survived the conversion. bcftools stats gives counts that you can compare between the input and output.

bcftools stats cohort.vcf.gz > stats.vcf.txt
bcftools stats cohort.bcf > stats.bcf.txt

1. Spot-check a few regions in both files. Pick a region with simple variants, a region with multiple alternate alleles, and a region with missing genotypes if your data has them. Compare the records as text.

bcftools view -H -r chr1:1000000-1010000 cohort.vcf.gz
bcftools view -H -r chr1:1000000-1010000 cohort.bcf

1. Convert back to VCF as a round-trip check when the file is going to be shared or submitted.

bcftools view -Ov -o roundtrip.vcf cohort.bcf

1. Compare the header and a sample of records between the original VCF and the round-trip VCF. Text comparison is meaningful here because both files are text. A full checksum comparison may fail for harmless reasons such as header ordering or compression differences, so compare the fields you care about and use bcftools stats for counts.

This workflow does not prove that every annotation is semantically correct. It does catch the common failures: wrong output type, missing index, unsorted records, lost samples, and truncated files.

Worked Example: Inspecting One Variant in VCF and BCF

Suppose a reviewer asks why a particular variant was called in one sample and not another. The fastest way to answer is to look at the raw record. In a compressed VCF, you can use bcftools or zless. In BCF, you must use a parser or bcftools. The commands are similar enough that the format choice does not slow down the investigation.

For a VCF:

bcftools view -H -r chr7:55019017-55211628 calls.vcf.gz

For a BCF:

bcftools view -H -r chr7:55019017-55211628 calls.bcf

The output is text in both cases. You can read the REF, ALT, QUAL, FILTER, INFO, FORMAT, and sample columns. If you want a compact table of genotypes and depths, use bcftools query:

bcftools query -f '%CHROM\t%POS\t%REF\t%ALT[\t%GT\t%DP\t%GQ]\n' -r chr7:55019017-55211628 calls.bcf

This is one of the strongest arguments for keeping a BCF working copy. The file is opaque on disk, but the query interface is text-based and precise. You do not lose inspectability by choosing BCF. You lose the ability to use grep and awk directly on the file, which is a different capability.

If the same record looks different between a VCF and a BCF, the problem is almost never the encoding. It is usually one of four things: the files were generated from different call sets, one file has a different header declaration, one file was filtered after the other was written, or the region query is using a different contig naming convention. Compare the headers before you compare the records.

Worked Example: A Small Benchmark You Can Run Before Standardizing

Published benchmarks are useful for orientation, but they do not tell you what will happen on your storage, your CPU, and your variant density. A small local benchmark is worth running before you convert hundreds of files.

Pick a representative VCF. Record its size. Convert it to BCF. Record the BCF size. Time a full pass over the file with a simple command such as bcftools view -Ov to a null sink, and time a regional query that returns a small number of records. Run each command more than once so that disk cache does not mislead you. Then repeat with a BCF input.

A minimal sequence looks like this:

ls -lh cohort.vcf.gz cohort.bcf
time bcftools view -Ov cohort.vcf.gz > /dev/null
time bcftools view -Ov cohort.bcf > /dev/null
time bcftools view -H -r chr1:1000000-2000000 cohort.vcf.gz > /dev/null
time bcftools view -H -r chr1:1000000-2000000 cohort.bcf > /dev/null

Do not expect the numbers to match a published benchmark. The 1000 Genomes Phase 3 comparison reported a VCF at 14.0 Gb and a BCF at 12.3 Gb, with array-oriented formats much smaller still [3].

Frequently Asked Questions

Is BCF smaller than VCF?

Yes, but only modestly. In a published 1000 Genomes Phase 3 comparison, the BCF was 12.3 Gb against 14.0 Gb for the VCF [3]. Specialized compressors and array formats go much further.

Can I convert VCF to BCF without losing data?

Yes. BCF shares the VCF data model, so standard header lines, INFO and FORMAT fields, and genotypes round-trip losslessly in normal use. Use bcftools view -Ob to write BCF and bcftools view -Ov to return to text.

Which format should I use for a paper's supplementary data?

Use compressed VCF. Reviewers and readers can inspect it without special libraries, and most archives accept it. Keep the BCF as your internal working file if the cohort is large.

Do I need an index for both formats?

Yes. Any regional query needs an index. Compressed VCF is indexed with tabix or bcftools, and BCF is indexed with the CSI format through bcftools.

Does threaded bcftools speed up BCF processing?

No. The threaded option accelerates compression of the output only. Per-record work stays on a single core regardless of whether the input is VCF or BCF [7].

Can Python and R read BCF directly?

Yes, through htslib bindings. cyvcf2 provides fast parsing and querying of both VCF and BCF from Python [1], and vcfppR exposes the vcfpp C++ API to R [2].

Sources

1. cyvcf2: fast, flexible variant analysis with Python.
2. vcfpp: a C++ API for rapid processing of the variant call format.
3. SeqArray-a storage-efficient high-performance data format for WGS variant calls.
4. GSC: efficient lossless compression of VCF files with fast query.
5. VCFShark: how to squeeze a VCF file.
6. Insane in the vembrane: filtering and transforming VCF/BCF files.
7. pbcftools: parallel execution of bcftools for large variant call sets.
8. vcfgl: a flexible genotype likelihood simulator for VCF/BCF files.