HGVS Variant Converter — c. ⇄ g. ⇄ p. Coordinate Converter
Convert an HGVS c. variant to genomic (g.) coordinates and predict its protein (p.) effect, via a real, live Ensembl exon map.
🔒 Nothing you paste is logged or stored — the exon map is built live from Ensembl's REST API, so the accession and position you enter go to Ensembl
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. 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 matches what even the leading production HGVS tools (Mutalyzer, VariantValidator) themselves exclude.
Accession or gene symbol + a "c." edit — substitution (>), del, dup, ins, delins, or inv.
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 load the 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."), non-coding-transcript ("n."), protein-level ("p.") or genomic ("g.") descriptions as the INPUT (only "c." is accepted in); uncertain/mosaic/imprecise syntax (parentheses, "?", "spl"); and any gene/transcript not in the bundled MANE crosswalk or given as a raw Ensembl ID. This matches what the two leading production HGVS tools, Mutalyzer and VariantValidator, themselves exclude — an explicit refusal is honest, a guessed answer is not.
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.
Is my input stored, and can I use this from code?
No — never logged or stored. The exon map and reference bases come live from Ensembl's REST API, so the accession and position you enter do go to Ensembl. The hgvs_convert tool is available via the REST API and the MCP server.
More
Related tools
Look up a variant by rsID, chrom:pos:ref:alt, or HGVS and get its ClinVar significance, gnomAD allele frequencies, and CADD/SIFT/PolyPhen2/REVEL scores in one card.
Type or paste a sequence and edit it directly — every feature remaps live as you insert, delete, or replace bases, with undo/redo and GenBank import/export.
Per-base quality, GC and length distributions, duplication levels, overrepresented sequences and adapter content, each with a warn/fail verdict.