Direct comparison
gVCF vs VCF: Key Differences
gVCF adds reference blocks to plain VCF, letting GATK-style joint genotyping tell hom-ref calls apart from uncovered sites across a cohort.
Written and maintained by CASRAI Editorial Board
Last updated
Ask CASRAI · included with Regulatory Radar
Ask about gVCF vs VCF: Key Differences
Ask CASRAI answers research-administration questions and cites the passages behind every claim — and says so when the corpus does not cover something, instead of guessing. It comes with a Regulatory Radar subscription at $29 a month, alongside the daily digest of regulatory changes and the dashboard of what changed.
150 questions a day, on this site, over the API, or inside your own tools through the CASRAI MCP server.
Everything CASRAI publishes — this page, the dictionary, the guides and the news — stays free to read, with no account and no card.
How do Standard VCF, gVCF (Genomic VCF) compare side by side?
The table below compares Standard VCF, gVCF (Genomic VCF) across 8 procurement-relevant dimensions, from what it records through format standard.
Side-by-side comparison
| Dimension | Standard VCF | gVCF (Genomic VCF) |
|---|---|---|
| What it records | Only variant sites - positions where at least one sample differs from the reference or was otherwise called as a variant candidate. | Variant sites AND reference blocks - banded runs of confidently non-variant positions, with per-block confidence metrics. |
| Non-variant / reference regions | Not represented at all. A missing position could mean confident reference-homozygous, or could mean never assessed - the file cannot tell you which. | Represented explicitly via reference-block records carrying a symbolic <NON_REF> ALT allele, with GQ/DP-style confidence metrics for that block. |
| Distinguishing hom-ref from not-assessed | Cannot - both look like "no record" at that position. | Yes - a reference block means the caller assessed and was confident in reference; no block at all means it was never assessed. |
| Typical file size (same sample) | Small - proportional to the number of variants found. | Much larger - proportional to genome length, since confidence is banded across nearly the whole genome, not just variant sites. |
| Typical scope | Usually a finished, multi-sample cohort file - the deliverable. | Conventionally one file per sample - an intermediate product, generated before the cohort is jointly genotyped. |
| Role in a GATK-style cohort workflow | The final output of GenotypeGVCFs - what downstream annotation/filtering tools expect to consume. | The per-sample input to CombineGVCFs/GenomicsDBImport, produced by HaplotypeCaller run in -ERC GVCF mode. |
| Adding a new sample to an existing cohort | Requires re-calling and re-merging the whole cohort from raw reads to genotype jointly and correctly. | Requires only generating the new sample's gVCF, then re-running combine + joint genotyping - existing samples' gVCFs are reused as-is. |
| Format standard | Defined directly in the VCF specification (samtools/hts-specs). | Not a separate spec - a VCF using reserved conventions (the <NON_REF> symbolic allele, the END INFO field for block spans) that GATK tools recognize. |
Common questions
Common questions about Standard VCF vs gVCF (Genomic VCF)
Is a gVCF a type of VCF file?
+
Yes. A gVCF uses the same VCF file format, header structure and mandatory columns as any other VCF - it is not a separate format. What makes it a 'g'VCF is the addition of reference-block records (with a symbolic <NON_REF> ALT allele) covering confidently non-variant regions, on top of the ordinary variant records a ordinary VCF already has.
Can I use a gVCF directly with normal VCF tools, like bcftools or an annotation pipeline?
+
Not usually as a final deliverable. A gVCF still contains reference-block records with the <NON_REF> placeholder allele, which most downstream annotation, filtering and reporting tools do not expect to see. The intended path is to run the gVCF through joint genotyping (e.g. GATK's GenotypeGVCFs) first, producing an ordinary genotyped VCF, and feed that into downstream tools instead.
Why can't I just merge each sample's separately-called VCF instead of using gVCFs?
+
Because a plain per-sample VCF never recorded what happened at non-variant sites, a merge has no way to tell whether a sample missing from the merged file at a given position was confidently reference-homozygous or simply never assessed there. Joint genotyping needs that distinction for every sample at every candidate site to compute correct genotype likelihoods across the cohort; gVCFs supply it, a merge of ordinary VCFs does not.
What does the <NON_REF> allele in a gVCF actually mean?
+
It is a symbolic placeholder ALT allele used inside a reference-block record, not evidence that a variant was found. It lets the caller attach genotype-likelihood-style confidence to 'this position is reference' using the same statistical machinery used at real variant sites, so that confidence can be correctly recombined later against other samples' evidence at that same position during joint genotyping.
Does every variant caller produce or use gVCFs the way GATK does?
+
No. The reference-block-plus-joint-genotyping pattern described here is specifically GATK's cohort-calling design (HaplotypeCaller in -ERC GVCF mode, then CombineGVCFs/GenomicsDBImport, then GenotypeGVCFs). Other callers may not emit gVCFs at all, or may implement cohort calling differently - check a given toolchain's own documentation before assuming a gVCF it produces will combine cleanly with a different pipeline's joint-genotyping step.
Going deeper
