VCF vs gVCF: What's the Difference

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

A VCF file lists only the genomic positions where at least one sample carries an allele that differs from the reference, while a gVCF (genomic VCF) records every position in the callable region of the genome, writing invariant stretches as compressed reference blocks. A VCF is the delivery format for variants. A gVCF is the working format for joint genotyping, cohort expansion, and reanalysis.

The rule of thumb that decides most real projects: if you are handing genotypes to a downstream analyst, a database, or a publication supplement, ship a VCF. If you are feeding a joint-genotyping engine, adding samples to an existing cohort, or keeping raw material for future reanalysis, keep gVCFs.

That one-line answer hides a lot of practical detail. The two formats share the same column grammar, the same header syntax, and the same specification family. They differ in what they choose to write down, and that choice drives file size, tool compatibility, and the questions you can answer later without going back to the alignments.

Quick Answer and Rule of Thumb

The core difference is scope of representation.

• VCF answers: where does this sample (or these samples) differ from the reference?
• gVCF answers: what did the caller see at every position, including the positions where nothing differs?

A gVCF is not a competing file standard. It is a profile of the same VCF specification, using a symbolic non-reference allele and an end coordinate to collapse long runs of homozygous-reference evidence into single rows. The record layout underneath is still VCF.

A useful decision heuristic, in order of priority:

1. Will another sample be added to this cohort later? Keep the gVCFs.
2. Does the downstream tool expect per-sample genotypes at every site? Keep the gVCFs and joint-call.
3. Is the output going to a clinical report, a GWAS, a variant browser, or a public archive? Publish a VCF.
4. Is storage the binding constraint at biobank scale? Neither plain VCF nor plain gVCF is the final answer, and reference-block-aware representations are the direction the field is moving [1].

The rest of this article unpacks each of those answers.

Sorting Out bioinformatics file formats: FASTQ, FASTA, BAM, VCF, gVCF

Before comparing the two variant formats, it helps to place them in the assembly line. Most confusion about VCF versus gVCF comes from mixing up the layers of that line.

FASTQ: raw reads with quality

FASTQ is the sequencing instrument's output. Each record has four lines: a header beginning with @, the read sequence, a separator line beginning with +, and a per-base quality string encoded as ASCII characters. The quality string is the point. A FASTQ tells you not just what base the instrument saw but how confident it was.

FASTQ is the correct format for raw read deposition (NCBI Sequence Read Archive, EMBL-EBI European Nucleotide Archive) and for the input to alignment.

FASTA: sequence without quality

FASTA has two lines per record: a header beginning with > and the sequence. No per-base quality. FASTA is used for reference genomes, transcript sequences, protein sequences, and any context where the sequence itself is the deliverable and base-level confidence is not per-base.

The fastq vs fasta distinction is therefore about quality scores and read structure, not about variants. Neither format says anything about how a sample differs from a reference.

SAM and BAM: aligned reads

SAM is the text alignment format, BAM is its binary, block-compressed equivalent, and CRAM is the reference-based compressed alternative. These carry reads mapped to a reference with mapping quality, CIGAR strings, and mate information. Variant callers read BAM or CRAM.

VCF and gVCF: variant evidence

VCF and gVCF sit downstream of alignment and variant calling. They summarize the evidence per site rather than storing reads. Both are text formats with a binary sibling, BCF, produced by bcftools and by htslib-based tools.

A compact mental model:

The FASTQ to BAM to gVCF to VCF chain is the standard germline short-variant path in GATK-style pipelines. Many newer pipelines skip the gVCF stage and go straight from per-sample calling to cohort merging, which is one reason the gVCF question keeps resurfacing.

Anatomy of a VCF File

Understanding what a VCF does and does not store makes the gVCF look less mysterious.

A VCF file has three parts.

1. The meta-information header

Lines beginning with ## declare the file format version, the reference assembly, contig lengths, INFO field definitions, FILTER definitions, FORMAT definitions, ALT definitions for symbolic alleles, and provenance metadata. A minimal example includes declarations such as ##fileformat=VCFv4.2, ##contig=<ID=chr1,length=248956422>, and ##INFO=<ID=DP,Number=1,Type=Integer,Description="Total Depth">.

This header is where interoperability is won or lost. A published analysis of VCF formatting for plant genotyping data found that the flexibility of the specification makes VCF a usable interchange format across domains but also permits wide inconsistency in how metadata is presented, and argued that controlled vocabularies and resolvable identifiers are needed in the header for data to be machine-actionable under FAIR principles [2]. The same reasoning applies to any VCF you intend to publish.

2. The column header line

A single line beginning with #CHROM defines the eight fixed columns and then one column per sample:

#CHROM POS ID REF ALT QUAL FILTER INFO FORMAT SAMPLE1 SAMPLE2 ...

3. The data body

Each row is one variant site. The fixed columns carry chromosome, 1-based position, identifier, reference allele, alternate allele(s), phasing-aware quality, filter status, and INFO annotations. The FORMAT column gives the genotype field keys (for example GT:AD:DP:GQ:PL), and each sample column gives the values in that order.

Key properties that matter for the VCF versus gVCF comparison:

• Rows exist only where variation exists. A human germline VCF against GRCh38 typically contains roughly 4 to 5 million rows per sample. The genome is about 3.1 billion bases. The VCF is therefore a sparse, tiny slice of the genome.
• Sites with no variation are absent, not recorded. The absence of a row at position 1,234,567 means "no variant was emitted there", not "this position was confidently homozygous reference". That distinction is the entire reason gVCF exists.
• Multi-allelic sites are compressed into one row. ALT=A,T with GT=1/2 is legal and common.
• Symbolic and breakend alleles exist. <DEL>, <INS>, <DUP>, <INV>, <CNV>, and breakend notation cover structural variation.
• Genotypes may be missing. ./. means no genotype was assigned. .|. means phased but unassigned.
• Phasing is expressed with | instead of /. 0|1 is a phased heterozygous genotype.
• BCF is the binary equivalent. It stores the same information with typed encoding, and it indexes and queries far faster.

A VCF is an assertion set, not a record of everything the caller examined. That is its strength (compact, portable, human-inspectable) and its weakness (you cannot tell a confidently homozygous-reference site from a site that was never covered).

What Makes a gVCF Different

A gVCF answers the question a VCF cannot: at this position, did the caller have evidence, and what was it?

The format keeps the entire VCF grammar and changes two conventions.

Reference blocks

Runs of consecutive positions that share the same homozygous-reference genotype, or the same no-call status, are collapsed into a single record whose INFO field carries END=<stop position>. One row can stand for a hundred kilobases of invariant genome. This is how a gVCF can cover a whole genome without exploding to three billion rows.

A block record is not a variant. It is a compact statement that every position from POS through END has the same genotype and the same supporting depth characteristics within the block's resolution.

A symbolic non-reference allele

Every record in a GATK-style gVCF includes a symbolic allele in the ALT column representing "any allele other than the reference was possible here but was not observed in this sample". GATK 4 writes <NON_REF> for this purpose. Earlier GATK 3 releases used <*> with a graph-genotyping mode. Both conventions carry the same meaning: this record is not asserting a specific alternate allele, and a later joint-calling step is allowed to assign one.

At an actual variant site, the gVCF row lists both the real alternate allele and the symbolic allele, for example ALT=T,<NON_REF>. This lets the joint genotyper treat the site as potentially polymorphic across samples even when only one sample has an alternate observation.

Why per-sample gVCFs precede joint calling

The classic reason to keep gVCFs is that a cohort's genotype at a site must be decided across all samples at once, not sample by sample. If sample A has a variant at position 1,000,000 and sample B does not, a merge of two sparse VCFs produces a row for position 1,000,000 with sample B's genotype as missing (./.) unless the merge tool explicitly inserts a reference genotype. If both samples contributed gVCFs, the joint caller already knows sample B was confidently homozygous reference at that position, with a depth value attached.

That distinction drives real differences in downstream analysis. In a study of Mycobacterium tuberculosis cluster detection, an optimized genomic VCF workflow, meaning GATK HaplotypeCaller plus GenotypeGVCFs, produced minimum cross-platform pairwise SNP differences of 2 to 14 SNPs, while VarScan 2 produced a range of 7 to 158 SNPs across the same comparison, and the gVCF-based workflow reached average nucleotide identity estimates of up to 99.7 percent between Illumina NextSeq500 and Ion Torrent PGM data for multidrug-resistant isolates [3]. Genotype representation choices change measured genetic distance, and the choice is not neutral.

What a gVCF is not

A gVCF is not a compressed VCF in the sense of bgzip or BCF. Compressing a VCF shrinks the bytes but keeps the same sparse set of records. A gVCF has different content, not just different encoding.

A gVCF is also not a final genotype set. Its genotypes for reference blocks are per-sample assertions, and its alternate alleles at variant sites are pre-cohort. Feeding a gVCF directly into an annotation pipeline usually produces the wrong answer or no answer, because most annotation tools expect a variant-only record set with explicit alternate alleles.

VCF vs gVCF: Side-by-Side Comparison

The table's most misunderstood row is file size. Many practitioners assume a gVCF is always larger. For deeply covered samples with few gaps, a single-sample gVCF is often only modestly larger than the equivalent VCF, because reference blocks are cheap. For low-coverage samples with many no-call stretches, a gVCF can be surprisingly large because blocks fragment. The comparison that matters is not single-sample storage but cohort storage and cohort reanalysis cost.

The Criteria That Decide Real Choices

Six criteria separate an academic discussion from a project decision.

1. Whether the cohort is closed or open

A closed cohort, such as a finished case-control study with fixed membership, needs one genotype set and nothing else. An open cohort, such as a biobank that adds samples quarterly, needs the per-sample evidence for every existing member. Re-calling a thousand exomes because sample 1,001 arrived is a week of compute. Adding one gVCF to an existing joint call is an afternoon.

The Scalable Variant Call Representation work makes this explicit by adopting reference blocks from the gVCF and combining them with local allele indices so that joint calling can proceed incrementally at N+1 and N+K [1]. The gVCF block is the part of the format worth preserving even when the container changes.

2. Whether the reference genotype matters scientifically

Some analyses care about confident homozygosity. Loss-of-function burden tests, somatic calling with matched normals, Mendelian error detection in trios, and contamination checks all benefit from knowing that a position was covered and reference, not just absent from the file. A VCF cannot express that. A gVCF can, at block resolution.

3. Whether you will reprocess with a different caller or reference

Publishing a VCF commits you to that caller's decisions. A gVCF preserves more of the per-site evidence, though not the raw reads, and lets a later pipeline re-derive genotypes with a different model. If you genuinely need full reprocessing flexibility, you need the BAM or CRAM. The gVCF is a middle ground.

4. Storage and egress cost at scale

The VCF format's scaling problem is not a rounding error. A widely cited estimate puts a 150,000-genome VCF at roughly 900 TiB, and the authors trace the problem to VCF's requirement to densely represent both reference genotypes and allele-indexed arrays, producing unnecessary duplication [1]. At that scale, the choice is not VCF versus gVCF. It is a reference-block-aware representation versus a naive one.

5. Tool chain compatibility

This is the most common practical constraint. Many tools read VCF and either fail on or mis-handle gVCF. Annotation engines want explicit alternate alleles. Association tools want a rectangular genotype matrix. Clinical interpretation software wants a variant list.

Multi-tool pipelines are a useful illustration. A published compound heterozygous variant pipeline encapsulates BCFtools or GATK4, Picard Tools for liftover, GATK4 for joint genotyping, Plink2 for conversion, SHAPEIT2, Beagle, or Eagle2 for phasing, vt tools for normalization, SnpEff for annotation, and GEMINI for relational storage across 13 steps. It accepts either VCF or gVCF as starting input, which is only possible because one of its steps is joint genotyping that absorbs the gVCF into a variant set [4]. Tools that lack that step generally do not accept gVCF.

6. Archival and publication requirements

VCF is the established standard for exchange and publication of genotyping data, and other formats that capture variant data, including gVCF, do not have its reach [2]. If the deliverable is a DOI, a supplement, or a repository submission, VCF (or BCF alongside it) is the format reviewers and repositories expect.

When to Use a VCF

Use a VCF in these situations.

Delivering results. Any file that leaves your compute environment for a collaborator, a clinician, a statistical geneticist, or a public repository should be a VCF. This is the format's home ground.

Running annotation. VEP, ANNOVAR, SnpEff, and similar tools expect one row per variant with concrete alternate alleles. A gVCF block record is not a variant and has nothing to annotate.

Genotype matrix analyses. GWAS, burden tests, relatedness estimation, PCA, and admixture analyses want a sample-by-site matrix. Convert a joint-called VCF to PLINK bed/bim/fam or feed it to Hail. Do not hand a gVCF to these tools.

Clinical reporting. Any interpretation workflow that filters on quality, allele frequency, consequence, and inheritance needs a finalized variant set. Reference blocks are noise in that context.

Publishing. A VCF with a complete, standards-compliant header is the community expectation [2].

Reproducibility archives. If you must archive one file and cannot archive the BAM or CRAM, a VCF plus the exact command line and reference build is a defensible minimum. A gVCF alone is not, because it is not a finished result.

A VCF is also the right choice when the cohort is genuinely closed and will never grow. Producing gVCFs for a fixed 40-sample study and then joint-calling once adds storage and a pipeline stage for no future benefit.

When to Use a gVCF

Use a gVCF in these situations.

Joint genotyping across samples. The canonical use. Per-sample gVCFs go into GenomicsDBImport or CombineGVCFs, then GenotypeGVCFs produces the cohort VCF. The gVCFs stay on disk as the raw material for the next cohort version.

Open and incremental cohorts. Any study that adds samples over time should retain gVCFs. Incremental joint calling at N+1 and N+K is exactly what reference-block-carrying representations are designed to support [1].

Trio and pedigree analysis. Knowing that a parent is confidently homozygous reference at a child's candidate de novo site is essential. A missing genotype and a reference genotype are not the same thing. Trio-aware pipelines such as CompoundHetVIP accept gVCF input and perform joint genotyping as one of their steps precisely to make this possible [4].

Studies where batch effects alter genotype representation. The tuberculosis cluster study is the clearest published example. Comparing cross-platform sequencing data with a gVCF-anchored workflow produced minimum pairwise SNP differences of 2 to 14, whereas VarScan 2 produced 7 to 158 over the same samples, and the gVCF workflow achieved the highest cross-platform average nucleotide identity values reported in that comparison [3]. When the scientific question is distance between genomes, the genotype representation deserves this level of attention.

Long-term institutional data assets. A sequencing core or a biobank that intends to re-derive variant calls under future pipelines should store gVCFs alongside CRAMs. They are cheaper than keeping every intermediate VCF version and more informative than keeping only the current call set.

Regions of interest with high coverage. Targeted panels and exomes generate gVCFs that are manageable and informative, because the callable territory is small and the reference blocks are long.

What a gVCF is not good for: final delivery, annotation input, association testing, and anything a collaborator will open in a variant viewer.

Worked Scenarios

Scenario 1: A 60-sample clinical exome study, closed enrollment

Sixty exomes, trio-structured, analyzed once, reported to ordering physicians.

The right pipeline is per-sample gVCF generation, joint genotyping across all 60, hard filtering or VQSR, then annotation of the final VCF. Keep the gVCFs (they are small for exomes) because the trio analysis and any future reanalysis will want them. Deliver the joint-called, filtered, annotated VCF.

Choosing VCF only, meaning per-sample calling followed by bcftools merge, would work but would produce missing genotypes at sites where a sample was confidently reference, degrading de novo and recessive analyses.

Scenario 2: A biobank adding 5,000 genomes per quarter

Per-sample gVCFs, incremental joint calling, and a scalable representation. Standard multi-sample VCF at this scale is not viable on storage grounds, since VCF's dense representation of reference genotypes and allele-indexed arrays drives file growth beyond linear with sample count [1].

The practical design: store per-sample gVCFs or CRAMs, build the cohort call set in a reference-block-aware representation such as SVCR-VCF or VDS, and materialize a plain VCF only when a downstream consumer demands one.

Scenario 3: A bacterial outbreak investigation

Twelve M. tuberculosis isolates, two sequencing platforms, a question about whether two isolates are within a 12-SNP threshold.

The study that examined this exact design compared four callers and found the GVCF workflow's cross-platform pairwise SNP differences ranged from 2 to 14 while VarScan 2 ranged from 7 to 158 [3]. The takeaway is not that one caller is universally correct. It is that the workflow's genotype representation has to be chosen deliberately and documented, because the same biological distance can be measured very differently.

For a bacterial genome of roughly 4.4 Mb, a gVCF is small enough that keeping it costs almost nothing.

Scenario 4: A single diagnostic sample, one patient, urgent

You need variants, fast, with a defensible filter chain, and the report goes out today.

Call with a standard caller, produce a VCF, annotate, filter, report. A gVCF adds a joint-genotyping stage that a single sample does not need. If your caller requires -ERC GVCF as an intermediate, run GenotypeGVCFs on that single-sample gVCF and move on. Do not archive the gVCF as if it were the result.

Scenario 5: Converting an existing VCF to a gVCF after the fact

You can do this, and it is a common request. The conversion is a re-genotyping step, not a relabeling. Tools such as GATK can take a VCF and a reference and emit a gVCF-shaped file, but the reference-block genotypes will be inferred from the VCF plus whatever depth information is present in the header and INFO fields. Any position the original VCF never touched remains unknown.

The honest framing: converting a VCF to a gVCF recovers less information than generating the gVCF from the BAM in the first place. If the BAMs still exist, regenerate.

File Size and Scale: The Storage Argument in Numbers

Storage is where the VCF versus gVCF discussion becomes urgent rather than academic.

The published estimate is concrete: a 150,000-genome VCF would occupy roughly 900 TiB, making it both costly and complicated to produce and analyze [1]. The cause is structural. VCF requires dense representation of reference genotypes and allele-indexed arrays, which duplicates information that is mostly the same across samples [1].

Two observations follow.

First, a per-sample gVCF is not automatically smaller than a per-sample VCF. It contains extra reference-block records, plus the <NON_REF> allele on every variant row. For a 30x whole genome with good coverage, a gVCF is typically in the same order of magnitude as the VCF, sometimes 1.5 to 3 times larger depending on block structure and depth fields retained.

Second, the cohort-level comparison is where reference blocks win. Because a gVCF encodes "this sample is reference from here to here", the joint call does not need to store a per-sample reference genotype at every site in a dense matrix. That is the design logic behind SVCR, which adopts gVCF reference blocks and local allele indices to achieve file sizes that grow linearly with sample count rather than super-linearly [1].

The lesson for anyone designing a pipeline today: treat the gVCF as the durable per-sample artifact and treat the cohort VCF as a generated view. Regenerate the view when needed, and store the raw material once.

Tool Compatibility and Pipeline Design

Practical command patterns make the division of labor concrete.

Generating a per-sample gVCF

gatk HaplotypeCaller \
  -R reference.fa \
  -I sample.bam \
  -O sample.g.vcf.gz \
  -ERC GVCF

The -ERC GVCF flag is what tells the caller to emit reference blocks and <NON_REF> records instead of a sparse variant file. Without it, the output is a conventional VCF.

Joint calling from many gVCFs

gatk GenomicsDBImport \
  --sample-name-map cohort.map \
  --genomicsdb-workspace-path gdb_workspace \
  -L intervals.bed

gatk GenotypeGVCFs \
  -R reference.fa \
  -V gendb://gdb_workspace \
  -O cohort.vcf.gz

For small cohorts, CombineGVCFs replaces GenomicsDBImport. For cohorts in the thousands, GenomicsDB is the standard path.

Handling the output VCF

bcftools norm -m -any cohort.vcf.gz -Oz -o cohort.split.vcf.gz
bcftools view -i 'QUAL>=30 && FILTER="PASS"' cohort.split.vcf.gz -Oz -o cohort.filtered.vcf.gz
tabix -p vcf cohort.filtered.vcf.gz

bcftools norm -m -any splits multi-allelic records, which many downstream tools require. bcftools view -i applies an expression filter. tabix builds the index that enables region queries.

Where tools break

• Variant annotation. VEP, ANNOVAR, and SnpEff will not meaningfully annotate <NON_REF> blocks. Annotate the joint-called VCF.
• Association and matrix tools. PLINK, GEMINI, and most GWAS engines want a dense genotype matrix. Convert from the joint-called VCF, not from gVCFs.
• Multi-tool workflows. CompoundHetVIP explicitly supports VCF or gVCF input because it includes a GATK4 joint-genotyping step among its 13 stages [4]. Tools that skip joint genotyping generally do not.
• Variant viewers. IGV will display a gVCF, but block records render as long spans that are easy to misread as deletions or CNVs.

Common Mistakes and Limitations

Mistake: treating a gVCF as a deliverable. A gVCF is a per-sample intermediate. Sending one to a collaborator who asked for variants produces confusion at best and a wrong analysis at worst.

Mistake: merging per-sample VCFs and expecting a joint call. bcftools merge on sparse VCFs inserts missing genotypes where the other samples had no record. That is not the same as a reference genotype. Analyses that distinguish homozygosity from no-call will be biased.

Mistake: assuming gVCF always saves space. For a single deeply covered sample, the gVCF can be larger. The savings appear at cohort scale and in reanalysis cost, not in single-sample disk usage.

Mistake: forgetting the reference build. Both formats are meaningless without an explicit reference assembly in the header. A VCF without ##contig and ##reference lines is a file you cannot safely liftover, merge, or annotate.

Mistake: ignoring header metadata. The VCF header is where FAIR compliance lives or dies. Published recommendations emphasize controlled vocabularies, consistent field definitions, and resolvable identifiers, and note that these recommendations apply to gVCF as well as VCF [2]. A file with invented INFO keys and no definitions is technically parseable and practically unusable.

Mistake: mixing gVCF conventions. GATK 3-style <*> records and GATK 4-style <NON_REF> records are not interchangeable across every tool. Pick one convention per project and document it.

Mistake: not retaining the gVCF when the cohort might grow. Re-calling from BAMs is possible but expensive. Deleting gVCFs to save storage often costs more later than it saved.

Mistake: over-filtering before joint calling. Filtering a gVCF removes the evidence a joint caller needs. Apply hard filters and quality thresholds to the joint-called VCF, not to the per-sample intermediates.

Limitation: neither format stores raw evidence. Both VCF and gVCF are summaries. If the question requires re-aligning or re-examining reads, you need BAM or CRAM. Keep those if the science may demand it.

Limitation: reference blocks have resolution limits. A block record says "reference from here to here", not "reference with exactly this depth at every base". Depth variation within a block is compressed away. Analyses that need base-level depth should go back to the BAM or a coverage track.

Limitation: a gVCF is only as good as the caller that wrote it. The tuberculosis comparison showed the same samples yielding pairwise SNP distance ranges from 2 to 14 under one workflow to 7 to 158 under another [3]. Format choice does not fix caller choice.

Individual research and clinical questions still require judgment about which pipeline and which format fit the specific dataset, and for diagnostic decisions that judgment belongs with a qualified clinical bioinformatician or laboratory director.

Frequently Asked Questions

What is the difference between VCF and gVCF?

A VCF records only positions where at least one sample differs from the reference, while a gVCF records every position in the callable genome, collapsing runs of invariant positions into reference blocks with an end coordinate.

Is a gVCF just a compressed VCF?

No. Compression (bgzip or BCF) changes the encoding of the same records. A gVCF changes which records exist, adding reference blocks and a symbolic non-reference allele at every site.

Can I annotate a gVCF directly?

Generally no. Annotation tools expect concrete alternate alleles, and reference block records have nothing to annotate. Joint-call or genotype the gVCF first, then annotate the resulting VCF.

Which file is smaller, VCF or gVCF?

For a single deeply covered sample, the gVCF is often larger. For cohort storage and repeated joint calling, the reference-block structure avoids dense per-sample reference genotypes and scales better with sample count [1].

Do I need gVCFs for joint genotyping?

It is the standard and most defensible route. Per-sample gVCFs preserve the reference genotype evidence that joint calling needs, and they are the input that GATK GenomicsDBImport and GenotypeGVCFs are built around.

Can I convert a VCF to a gVCF later?

You can, but the result is weaker than a gVCF generated from alignments, because positions the original VCF never recorded remain unknown. If the BAMs or CRAMs still exist, regenerate the gVCF from them instead.

Sources

1. The Scalable Variant Call Representation: Enabling Genetic Analysis Beyond One Million Genomes.
2. Recommendations for the formatting of Variant Call Format (VCF) files to make plant genotyping data FAIR.
3. An optimized genomic VCF workflow for precise identification of Mycobacterium tuberculosis cluster from cross-platform whole genome sequencing data.
4. CompoundHetVIP: Compound Heterozygous Variant Identification Pipeline.