Liftover Between Genome Assemblies: Why Coordinate Conversion Is Lossy and Silently Wrong for Indels

Zetobit Bioinformatics Insight Series

Coordinate Systems & Reference Builds

Liftover Between Genome Assemblies: Why Coordinate Conversion Is Lossy and Silently Wrong for Indels

Moving a variant from GRCh37 to GRCh38 looks like arithmetic on a position. It isn’t. Wherever the two assemblies spell the same variant with different alleles, the standard tools quietly drop it or convert it into something that will never match a natively called genome — and nothing in the output tells you it happened.

By Kanna Nandakumar, PhD · Zetobit

A remarkable amount of genomics still lives in GRCh37. Legacy clinical variant lists, published GWAS summary statistics, curated pathogenic databases, tumor panels validated years ago — all tied to a coordinate system that the field formally moved past in 2013. When any of it has to meet data called against GRCh38, or now the telomere-to-telomere CHM13 assembly, someone reaches for liftover: pass the coordinates through a chain file, get back the new positions, done.

The mental model behind that reach is that a genome build is a ruler, and changing builds is re-reading the same features against new tick marks. If that were true, liftover would be lossless and boring. It is neither. A genome assembly is not a ruler; it is a specific reconstructed sequence, complete with the particular alleles its donors happened to carry and the particular errors that were later corrected. When you move a variant between assemblies you are not renumbering a position — you are asserting that a variant defined against one sequence still means the same thing against a different one. For most single-nucleotide variants that assertion holds. For indels, for variants inside short tandem repeats, and for anything sitting where the two assemblies genuinely disagree about the underlying sequence, it can fail silently.

What a chain file actually encodes

Every liftover tool — UCSC liftOver, CrossMap, Picard LiftoverVcf, and the newer VCF-aware tools — needs a chain file. A chain is a pairwise alignment between two assemblies that permits gaps on both sides, filtered so that each base in the source assembly either maps to a unique base in the target or maps nowhere at all.¹ That filtering is the whole game. The regions that map cleanly are the easy ones; the interesting behavior is concentrated in the gaps — the places where a base in GRCh37 has no clean counterpart in GRCh38 because the sequence there was revised, an allele differs, or the local alignment simply broke.

A benchmark of liftover across the two builds put numbers on this: relative to hg19, some regions are gapped in hg38, some are gapped in hg19, and roughly 3.5% of the genome length falls in regions gapped in both assemblies.² Coordinates that land in those gaps don’t convert — and a variant is far more likely than a random base to sit in exactly such a region, because the polymorphism that made it a variant is often the same difference that the chain file couldn’t bridge.

The failure lives in the gaps. Matched chain blocks convert one-to-one. But a variant whose allelic difference coincides with a small gap in the alignment has no clean target base — the position-only tools reject it, and the tools that try to rescue it must guess which allele the new assembly carries.

SNVs are mostly fine. Indels are where it breaks.

For a single-nucleotide variant, liftover has an easy job: the variant occupies one base pair, so converting it is converting one coordinate. Even here there are edge cases — a SNV can sit in a one-base chain gap precisely because the new assembly carries the alternate allele at that site — but the scale is small. In a conversion of the low-coverage 1000 Genomes callset from GRCh37 to GRCh38, the position-only tools each dropped on the order of twenty thousand SNVs out of roughly 45.6 million, well under a tenth of a percent.¹

Indels are a different problem entirely, and the reason is representational. The same insertion or deletion can be written as several different VCF records — left-aligned or not, trimmed or padded — and, crucially, the two assemblies may represent the same variant using different reference alleles. Convert an indel by naively mapping the interval its reference allele covers and you can land on a record whose REF no longer matches the target sequence. The older, position-only tools handle this by dropping the variant or by emitting a record that is wrong. In the same 1000 Genomes conversion, the specialized tool BCFtools/liftover dropped fewer than a thousand indels while the widely used Picard/LiftoverVcf dropped over four thousand, and CrossMap and Picard cannot swap reference and alternate alleles for indels at all — so wherever a swap was required, they produced a discordant record rather than a flagged failure.¹

The dangerous case is not the dropped variant. A dropped variant is at least visible — it lands in the reject file, and you can count it. The dangerous case is the indel that converts to a plausible-looking record with the wrong allele, because it flows downstream and is never questioned.

The short-tandem-repeat trap

The cleanest illustration of why this is not fixable by arithmetic is a variant inside a short tandem repeat whose length differs between the two builds. Suppose GRCh37 and GRCh38 disagree on how many copies of a repeat unit sit at a locus. An indel called against GRCh37 — say, a one-unit contraction — may have neither of its alleles match the GRCh38 sequence, because the reference itself carries a different repeat count. The modern approach, used by BCFtools/liftover, is to map the flanking anchor bases of a maximally extended representation and, when an anchor falls in a gap, locally realign with a Needleman–Wunsch alignment to find where the anchor most likely belongs.¹ That recovers many cases the old tools lose. But even this can produce a converted record that is neither a clean SNV nor a clean indel — a “complex” record that, as the authors themselves note, cannot be expected to match a variant natively called against the new assembly and is for practical purposes a silent loss.¹

There is an even harder class underneath this. In regions that are inverted between GRCh37 and GRCh38, the strand flips, and palindromic SNVs — where the two alleles are reverse complements of each other — become genuinely ambiguous. A study of build conversion found that even manually lifting genotypes over before imputation did not fully resolve errors localized to inverted regions, where directly genotyped variants were dropped and then reimputed at lower quality.³ No amount of tooling recovers information the representation has thrown away.

Why the tool choice is not cosmetic

It is tempting to treat all liftover tools as interchangeable coordinate converters. They are not, and the differences fall exactly where clinical and population work is most sensitive. The position-only tools — UCSC liftOver on intervals, CrossMap and Picard on VCFs — do the interval mapping well but cannot reason about allele identity across assemblies. The VCF-aware tools (BCFtools/liftover, Transanno, Genozip/DVCF, GenomeWarp) differ in whether they can swap alleles, add a new reference allele, handle multi-allelic records, and recover variants that fall in chain gaps. GenomeWarp, by contrast, was deliberately built to be conservative, dropping difficult indels rather than risk converting them wrong.¹ That is a legitimate design choice — but only if you know that is the tradeoff you have selected.

Concretely, when picking a liftover path it is worth knowing:

• Whether the tool can swap REF/ALT for indels. If it cannot, every indel that differs in reference allele between builds is either dropped or silently wrong. Picard and CrossMap cannot; BCFtools/liftover and Transanno can.¹
• Which chain file you feed it. The UCSC chain (BLAT-derived) and the Ensembl chain are not equivalent — the Ensembl chain produced a much higher drop rate in direct comparison.¹ The chain file is a dependency with a version, not a constant.
• What the reject file contains. Read it. The count and the reasons are the only honest signal of how lossy the conversion was, and a clean-looking output VCF with a large reject file is not a clean conversion.
• Whether raw data still exists. If it does, this whole discussion may be moot — see below.

When you should not lift over at all

The most important operational point is the one the BCFtools/liftover authors make in their own discussion: liftover is a lossy procedure and is not a substitute for realigning sequence data against the new assembly when the raw reads are available.¹ Realigning and re-calling from FASTQ or CRAM will always produce a more faithful GRCh38 callset than converting a GRCh37 VCF, because it lets the aligner and caller use the actual target sequence rather than inferring it from a chain. Liftover exists for the cases where the raw data is genuinely gone — published GWAS summary statistics, legacy variant lists, third-party panels — not as a shortcut to avoid rerunning a pipeline you still have the inputs for.

This reframes the decision. Liftover is not the default path from one build to another; realignment is. Liftover is the fallback you accept, with eyes open, when realignment is impossible — and when you take that fallback, the indels, the repeat regions, and the reject file are where you should be looking, not the reassuringly converted SNVs that were never in doubt.

The practical rule. If you have the reads, realign. If you only have the variants, lift over with an allele-aware tool, pin the chain-file version, and treat the reject file as a first-class output — because the variants it doesn’t mention are not all safe, and the ones it does are the ones you were told about.

References

1. Genovese G, Rockweiler NB, Gorman BR, et al. BCFtools/liftover: an accurate and comprehensive tool to convert genetic variants across genome assemblies. Bioinformatics. 2024;40(2):btae038. academic.oup.com/bioinformatics/article/40/2/btae038
2. Luu P-L, Ong P-T, Dinh T-P, Clark SJ. Benchmark study comparing liftover tools for genome conversion of epigenome sequencing data. NAR Genomics and Bioinformatics. 2020;2(3):lqaa054. pmc.ncbi.nlm.nih.gov/articles/PMC7671393
3. Nelson SC, et al. Inverted genomic regions between reference genome builds in humans impact imputation accuracy and decrease the power of association testing. bioRxiv. 2022. biorxiv.org/content/10.1101/2022.02.19.481174

© Zetobit LLC · Bioinformatics Insight Series zetobit.com