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.
🌐 Sends the accession/gene symbol and position you enter to Ensembl's REST API to build the exon map and check reference bases — not processed on SeqBench's own server
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?
The accession/gene symbol and position you enter are sent to Ensembl's REST API to build the exon map and check reference bases; nothing is stored by SeqBench. The same stateless hgvs_convert tool is available via the REST API and the MCP server.
Related tools
Per-base quality, GC and length distributions, duplication levels, overrepresented sequences and adapter content, each with a warn/fail verdict.
Align several DNA or protein sequences and view a colored alignment with a consensus.
Predict restriction fragments and see the simulated agarose gel with a ladder.