HGVS Variant Converter — c. ⇄ g. ⇄ p. Coordinate Converter
Convert HGVS between c., g. and p.: a c. variant to genomic coordinates and its protein effect, or a genomic position back onto its MANE transcript — via a live Ensembl exon map.
Paste an HGVS coding-DNA ("c.") variant description — by gene symbol, RefSeq NM_ accession, or Ensembl transcript — and get its genomic (g.) coordinates, computed from a real exon/CDS map fetched live from Ensembl (transcripts are resolved through the bundled MANE RefSeq↔Ensembl crosswalk). Deletions, duplications and insertions are checked against the official 3' rule and normalized to their most-3' equivalent position if the input wasn't already there, and the protein (p.) effect is predicted wherever that's actually safe to compute. It also works the other way round: give a genomic ("g.") position on a chromosome or RefSeqGene — on GRCh38 or the older GRCh37 — and it is validated against the reference, placed on GRCh38, projected onto the MANE Select transcript that covers it, and converted back by this tool's own engine, which has to agree before any answer is shown. This tool is deliberately narrow: it refuses cleanly, rather than guessing, for anything outside that — see the FAQ for the full excluded-scope list, which is the same scope the production HGVS tools exclude.
A gene symbol or transcript + a "c." edit, a chromosome/RefSeqGene (NC_/NG_) + a "g." position, or a gene + a single amino-acid change ("p.").
How to use the HGVS Converter tool
- 1Paste a c. variant description, e.g. "NM_000546.6:c.215C>G" or "TP53:c.215C>G" — or a genomic position such as "NC_000017.11:g.7676154G>C" (or load an example).
- 2Read the converted g. coordinates, the 3'-rule normalization comparison (if a del/dup/ins wasn't already maximally 3'-shifted), and the predicted p. effect when one could safely be computed.
- 3Check the notes for anything the tool explicitly declined to compute (e.g. splice-junction proximity) rather than guess at.
Frequently asked questions
What's explicitly NOT supported?
By design, this refuses rather than guesses on: circular reference genomes ("o."); mitochondrial ("m.") variants (even with the correct rCRS accession NC_012920.1 — v1 has no bundled mitochondrial gene map); RNA-level ("r.") and non-coding-transcript ("n.") descriptions as the INPUT ("c." is accepted, "g." on a chromosome or RefSeqGene accession, and a single amino-acid substitution such as "TP53:p.P72R" when exactly one single-base change produces it — otherwise every candidate is listed; a "c." hung on a genomic accession needs its transcript named in parentheses); and uncertain/mosaic/imprecise syntax (parentheses, "?", "spl"). A "c." on a RefSeq transcript outside MANE is placed by NCBI and answered on the gene's MANE Select transcript. This matches what the two leading production HGVS tools, Mutalyzer and VariantValidator, themselves exclude — an explicit refusal is honest, a guessed answer is not.
Can I convert a genomic (g.) position to a c. description?
Yes. A "g." position on a chromosome (NC_) or RefSeqGene (NG_) accession, on GRCh38 or GRCh37, is validated by NCBI's variant service — a wrong reference base is refused there — and placed on GRCh38. Ensembl's variant recoder then names its description on the MANE Select transcript, and this tool converts that back to "g." with its own engine. The answer is shown only if the two agree: it rests on two independent conversions rather than one.
Why does the "normalized" description sometimes differ from what I typed?
HGVS's 3' rule requires "the most 3' position possible" to be reported for any deletion, duplication or insertion — the opposite of the left-alignment convention VCF/bcftools use. If your input wasn't already at that position (common when a variant falls inside a repeat, e.g. a homopolymer run), this tool shifts it as far 3' as the evidence allows and reports both the original and the normalized form. This is only attempted when the shift could never need to cross an exon/intron junction, and is not attempted at all for "delins" (an arbitrary replacement has no single well-defined "run" to shift).
Why wasn't the protein (p.) effect predicted for my variant?
Three cases abstain on purpose: the variant is intronic or within 3bp of a splice junction (matching Mutalyzer's own documented policy of warning and abstaining rather than guessing at a possible splicing effect); it's an inversion (the nomenclature rules themselves say inversions "are not used on protein level"); or it lies entirely in the UTR, outside the coding sequence.
Where do the genomic coordinates actually come from?
A real exon/CDS map fetched live from Ensembl's REST API for the resolved transcript (never bundled or assumed, since exon coordinates need to come from a current, authoritative source) — cross-checked internally between Ensembl's transcript-lookup and exon-overlap endpoints before being trusted. A gene symbol or RefSeq NM_ accession is first resolved to its matching Ensembl transcript via the bundled MANE (Matched Annotation from NCBI and EMBL-EBI) release 1.5 crosswalk, which covers the single "best" transcript per human protein-coding gene.
Can I use this from code?
Yes — the hgvs_convert tool is available via the REST API and the MCP server.