Ensembl Gene ID Versioning Explained

By Dr. Zubair Khalid, DVM, MS, PhD · 2026-11-11

Ensembl gene ID versioning is the system in which Ensembl attaches a permanent stable identifier, such as ENSG followed by digits, to the same gene across annotation releases, while appending a numeric version suffix, such as .9, that is incremented whenever the annotated model of that gene or transcript is revised. The identifier is the gene's permanent name. The version is the edition of the annotation.

This distinction matters because almost every downstream analysis you will ever run, from differential expression to enrichment testing to variant interpretation, begins with a list of identifiers that someone produced under a specific annotation release. If you cannot read an identifier and say which edition of the annotation it came from, you cannot reproduce your own analysis six months later, and you cannot safely merge your results with a collaborator's. Studies routinely pull identifiers from different releases without noticing. A paper that analyzed single nucleotide variants in the EPCAM gene, for example, explicitly recorded the transcript it worked with as the Ensembl ID ENST00000263735.9 together with the NCBI RefSeq accession NM_002354.3, because those version strings are the only honest way to state which annotation edition was analyzed [1]. This article explains what the version suffix means, why it changes, how it differs from release numbers and genome assembly names, and how to handle versioned identifiers in real analysis workflows.

What Ensembl Gene ID Versioning Means

The Anatomy of an Ensembl Identifier

Ensembl, produced by EMBL-EBI, assigns stable identifiers to genes, transcripts, proteins, exons, and arrays. Each identifier has three parts:

1. A species prefix. Human identifiers carry no prefix, so human gene IDs begin with ENSG. Mouse IDs begin with ENSMUSG, rat with ENSRNOG, and zebrafish with ENSDARG.
2. A type letter. G means gene, T means transcript, P means protein, E means exon.
3. A numeric block, typically eleven digits, that is unique within that species and type. Newer identifiers can carry twelve digits, because Ensembl extended the numeric space for entries created in recent releases.

So a human gene identifier reads ENSG plus eleven digits, its transcripts read ENST plus digits, and its proteins read ENSP plus digits. The EPCAM transcript studied by Razzaq and Naseem, ENST00000263735.9, follows exactly this pattern. The prefix ENST marks it as a human transcript, the numeric block 00000263735 is its stable identity, and the suffix .9 is the version [1].

One identifier family maps onto the others through the annotation. A gene identifier (ENSG) groups one or more transcript identifiers (ENST), and each protein-coding transcript points to one protein identifier (ENSP). The gene ID, the transcript ID, and the protein ID each have their own independent version number, because each model can change independently. A transcript can gain an extra exon while the gene keeps the same boundaries, and in that case the transcript version increments while the gene version may not.

What the Version Number Actually Tracks

The version suffix records the edition of that specific annotated model. Ensembl increments the version when the underlying model changes, most visibly when the sequence changes. If a transcript model gains an exon, or the predicted protein sequence of a protein-coding transcript changes, the transcript version increments and the linked protein version increments as well. If the gene model itself is restructured, the gene version increments. If nothing about the model changes between releases, the version suffix stays the same even though the release number has moved forward.

This has two practical consequences for ensembl gene id versioning interpretation. First, the version suffix is a change log entry, not a ranking. ENST00000263735.9 is not better than ENST00000263735.8 in any biological sense. It is simply the ninth edition of that transcript model. Second, the version suffix lets you detect drift. If your collaborator sends a gene list built on ENST00000263735.8 while your pipeline was built on .9, you know immediately that the two lists were produced against different annotation states, and you can decide whether the difference matters for your question.

Version Numbers, Releases, and Genome Assemblies Are Three Different Things

The most common confusion in ensembl gene id versioning explained questions is conflating three separate layers of the annotation system. Ensembl updates its annotation in numbered releases, issued several times per year. Each release is built on a genome assembly, such as GRCh37 or GRCh38 for human, which is the coordinate system and underlying sequence. Within any release, individual stable identifiers carry their own version suffixes. PhyreRisk, a web application for mapping human genetic variants onto protein structures, accepts input as Ensembl coordinates, VCF records, reference SNP IDs, or HGVS notation, and explicitly supports both GRCh37 and GRCh38, which illustrates how tools must treat the assembly as an input choice separate from the identifier question [2].

A useful mental model is a library. The assembly is the building, fixed for years at a time. The release is a full reprint of the catalog several times a year. The stable ID is a book that keeps its title across reprints. The version suffix is the edition number printed on the title page, which changes only when the editors revise the text.

Why Versions Change at All

Annotation is a moving target, and the version suffix exists precisely because it must be. Gene models, especially their untranslated regions, remain incompletely characterized even in well-studied organisms. Morgan and colleagues used comparative genomics and transcriptomics across vertebrates to show that many conserved 3′ ends, including alternative 3′UTR isoforms of ADD2 and CPEB3 that they had previously reported, were simply absent from the Ensembl and RefSeq human annotations current at the time, and they went on to predict and validate several hundred novel 3′UTR extensions in rats and dogs [3]. When an annotation consortium adopts findings like these, the transcript models gain sequence at the 3′ end, and every affected transcript version increments in the next release. The version suffix is the visible fingerprint of that curation.

Assembly quality feeds into the same process. Watson and Warr documented that even after multiple rounds of correction, long-read de novo assemblies can contain errors in protein coding regions that substantially alter, and often truncate, protein predictions, with PacBio and Oxford Nanopore per-read error rates on the order of 5 to 15 percent contributing to the problem [4]. When a consortium improves a reference assembly, or improves the gene prediction pipeline run over it, large numbers of gene models change, and version numbers rise across the annotation in a coordinated wave. This is why a jump from one annotation edition to the next can coincide with a batch of transcript version increments, and why analyses built on non-reference assemblies can produce protein predictions that do not match any Ensembl release.

How Ensembl Keeps Stable IDs Stable Across Releases

The design goal of the stable ID system is that an identifier should never silently change meaning. Ensembl maintains stable ID history across releases and classifies the fate of every identifier between two releases. The event types you will encounter in practice are the following.

1. Identical. The model survived the release unchanged, and both the identifier and the version suffix carry over.
2. Version changed. The model was revised, so the identifier carries over with an incremented version suffix.
3. New. The model has no predecessor in the previous release, so it receives a fresh identifier at version 1.
4. Merged. Two previously separate models were combined into one, and one identifier absorbs the other.
5. Split. One model was divided, and the pieces receive new identifiers.
6. Discontinued. The model was removed, for example when a gene was judged to be an artifact, and the identifier is retired rather than reused.

These mappings are published as stable identifier history files, and the REST API exposes ID mapping endpoints that resolve identifiers between releases. The critical guarantee is that a retired identifier is not recycled for a different gene. If you meet an ENSG identifier in an old dataset, that string will always refer to the same biological entity in Ensembl's history, even if the current release no longer contains it. That guarantee is what makes cross-study meta-analysis possible at all, and it is the reason you should never "clean up" old identifiers by editing their numeric blocks.

The archive system is the other half of this design. Every Ensembl release remains browsable at a date-named archive site, so a result generated against a specific release can be checked against that exact snapshot years later. When reproducing published results, going to the archive site for the release named in the paper is the fastest way to see the annotation exactly as the authors saw it.

How to Use Ensembl in Practice

For readers searching for a practical ensembl genome browser tutorial, the workflow below covers the three ways most analysts interact with Ensembl and shows where the version suffix appears in each.

Reading a Gene Record in the Genome Browser

Start at the Ensembl main site and search for a gene symbol such as EPCAM. The gene landing page displays the stable gene identifier and its version, the assembly and release in the page header, and a tabbed view of transcripts. Each transcript line shows its identifier with its version suffix, its biotype such as protein coding, and its relationship to the canonical transcript. Clicking a transcript takes you to a page showing the transcript identifier with version, the linked protein identifier with version, the exon structure, and the sequence exports. Three habits are worth building here. Record the release number shown in the header every time you export data. Note whether you are viewing the default assembly or an alternative assembly such as a patch or an older build. And when you copy an identifier out of the browser, decide deliberately whether to keep the version suffix, because pasting an unversioned ID into your notes destroys the provenance of your annotation choice.

Fetching Data Programmatically

The Ensembl REST API returns identifiers, sequences, and mappings over plain HTTP requests, which makes it usable from any language. A minimal retrieval of the transcript sequence for the EPCAM transcript discussed above looks like this in a terminal:

curl -H "Content-type:text/plain" \
  https://rest.ensembl.org/sequence/id/ENST00000263735.9

The API accepts both versioned and unversioned identifiers. When you supply the versioned form, you are asking for that specific edition, and the service can respond if the requested version no longer matches the current release. When you supply the unversioned form, you get whatever the current release holds, which is convenient for exploratory work and hazardous for reproducible work. Rate limits apply to anonymous use, and the API returns the release number in its response headers, which you can log as part of your pipeline's provenance record.

In R, the biomaRt package connects to Ensembl BioMart and lets you pin both a release and an assembly. A short session that pulls versioned identifiers for one gene looks like this:

library(biomaRt)
ensm <- useEnsembl(biomart = "genes",
                   dataset = "hsapiens_gene_ensembl",
                   version = 110,
                   GRCh = 37)
getBM(attributes = c("ensembl_gene_id",
                     "ensembl_gene_id_version",
                     "external_gene_name"),
      filters = "external_gene_name",
      values = "EPCAM",
      mart = ensm)

The version argument pins the release and the GRCh argument selects the assembly, so the query is anchored to one definable annotation snapshot. BioMart exposes the versioned identifier as its own attribute, which means you can retrieve version suffixes in bulk rather than scraping them, and you should make ensembl_gene_id_version a standard column in every export your pipelines produce.

Pinning a Release for Reproducibility

Every analysis that will ever be rerun should name its annotation source in three parts: the release number, the assembly, and whether identifier versions were retained. Archive sites make the first two auditable, because anyone can open the same release later. Keeping version suffixes makes the third auditable, because a reader can compare your listed transcript versions against the archived release and confirm the exact models you used. A methods sentence that names the release and assembly, and a supplementary table that carries versioned identifiers, together satisfy the standard that papers like the EPCAM variant study meet when they report ENST00000263735.9 alongside NM_002354.3 [1].

Ensembl Versions in Downstream Analysis Workflows

ID Mapping Before Enrichment Analysis

Functional enrichment tools differ in which input identifier types they accept, and this is a documented design variable rather than an implementation accident. The WebGestalt2 authors list supported input ID types as one of the major axes on which enrichment tools differ, alongside the statistical test, supported organisms, and coverage of functional categories. In practice this means a versioned Ensembl transcript identifier that maps cleanly in one tool may be rejected or silently dropped in another. The safest pattern is to map your identifiers to the type the tool expects, using the version suffix as a quality control signal. If a mapping step converts only a fraction of your versioned identifiers while converting nearly all of the unversioned ones, the mismatch in versions across your input list is usually the cause, because some identifiers in your list were current in an older release and their versioned forms no longer resolve in the mapping database you supplied.

A pragmatic policy: strip version suffixes for mapping steps where the mapping resource itself is release-agnostic, keep them everywhere else, and always archive the versioned original list before stripping. The stripped list is derived data. The versioned list is your record.

Dual-List Comparison and Cross-References

Comparative designs amplify versioning problems, because now two lists must agree on identifiers before any comparison is meaningful. GeneAutomate, a browser-based platform for side-by-side comparison of two gene lists, performs over-representation analysis against Gene Ontology and Reactome with an exact hypergeometric test and Benjamini-Hochberg correction, adds gene set enrichment analysis when ranked input is provided, and extracts protein-protein interaction subgraphs from BioGRID, with all reference data including NCBI and Ensembl identifier cross-references pre-compiled offline into a single integer-indexed human database of approximately 32 MB [5]. The design lesson from that architecture is worth internalizing even if you never use the tool itself. Because the cross-reference tables are fixed at build time, the tool's behavior with your input identifiers is deterministic and reproducible, but the flip side is that identifiers from a much newer annotation release may not resolve against the built-in cross-references. Any tool with a fixed internal identifier database has this property. When a comparison between a discovery cohort and a validation cohort produces an implausibly small overlap of mapped genes, check the annotation vintage of each list before believing the biology.

Variant and Protein Mapping

Variant interpretation workflows add a coordinate dimension to the versioning problem. PhyreRisk accepts genomic coordinate formats including Ensembl notation, VCF, reference SNP IDs, and HGVS, across both GRCh37 and GRCh38, and reports structural coverage for 70 percent of the human canonical proteome, 14,035 of 20,214 canonical proteins, drawing on 18,874 experimental structures and 84,818 prebuilt models [2]. When you feed coordinates into such a tool, the assembly you declare determines where the variant lands, and the transcript identifier you declare determines which protein model the variant is translated against. A variant mapped with an outdated transcript version can be assigned to an isoform that no longer exists in the current release, or can miss an exon that the newer model added. Declaring the assembly and using versioned transcript identifiers together is what keeps this class of tool honest about what it did with your data.

Ensembl Versions Versus RefSeq Versions and Other Identifier Systems

Ensembl versioning is one of several versioning systems you will meet, and each behaves differently. RefSeq accessions carry their own dot suffixes. The EPCAM study cited above worked with the Ensembl transcript ENST00000263735.9 and the RefSeq transcript NM_002354.3 as a paired pair of records for the same biological transcript, and both suffixes were needed to pin down exactly what was analyzed [1]. The two suffixes are not interchangeable. An Ensembl transcript version increments when Ensembl revises its model. A RefSeq accession version increments when NCBI revises its record. The numbers are therefore independent, and a transcript can sit at version .9 in one system while its counterpart sits at version .3 in the other, as in this exact case.

HGVS notation is a different system again. It describes variants relative to a named reference sequence, for example a RefSeq accession with its version, so the versioning lives inside the notation string and is mandatory for unambiguous interpretation. A VCF record, by contrast, anchors a variant to a coordinate in a named assembly, so the assembly name does the versioning work. PhyreRisk's acceptance of all of these formats, Ensembl notation, VCF, reference SNP IDs, and HGVS, across GRCh37 and GRCh38, reflects the reality that analysts must move fluently between systems whose versioning logic differs [2]. The rule of thumb is that every coordinate or sequence claim in your analysis should carry one unambiguous versioned anchor, and you should know which system that anchor belongs to.

Misconceptions About Ensembl ID Versioning

A version bump means the gene moved to a new location. Location changes usually coincide with assembly changes, not with ordinary version increments. A version bump means the annotated model of that gene, transcript, or protein was revised. The gene's identity is anchored by the stable identifier, which does not change.

Stripping the version suffix loses nothing. The suffix is the only record of which edition of the annotation produced the sequence and coordinates you analyzed. Stripping it from your archived data destroys reproducibility. Stripping it at a mapping step, after archiving the original, is a legitimate convenience.

Two identifiers with the same gene symbol are the same gene. Symbols change hands, get reused, and apply to multiple genes in some cases. Stable identifiers exist precisely because symbols are unreliable keys. Never merge or compare gene lists on symbols when Ensembl identifiers are available.

A higher version number means a more current gene. Version numbers count revisions of one model, and different models have different histories. ENST00000263735.9 and another transcript at version .2 may both be current in the same release [1]. Version numbers are not comparable across identifiers.

The version number tells you the release. It does not. A transcript at version .9 could have received its ninth edition in any of many releases. Only the release number, recorded at the time of analysis, tells you the release.

Changing the assembly does not affect gene models. Assembly changes can trigger wholesale annotation changes, and assembly errors propagate into gene models. Long-read assemblies with residual errors in coding regions can yield truncated protein predictions, which is exactly the failure mode documented for de novo assemblies [4]. Treat an assembly change as a potential annotation change.

Common Mistakes and Limitations

Mixing releases within one analysis. The most damaging error is merging a gene list produced under an older release with identifiers downloaded from the current release and treating the result as one list. The symptom is usually a subset of identifiers that fails to map or to convert. The fix is to pin every acquisition step to one release, most easily through archive sites or a versioned BioMart connection, and to record the release in the output.

Mapping versioned identifiers against unversioned reference tables. If your mapping table holds unversioned identifiers and your input holds versioned ones, an exact string match will fail for every input whose version suffix does not equal the current suffix. Normalize by stripping suffixes before exact matching, but keep the versioned originals in your record.

Assuming the current annotation is complete and final. Gene models, particularly untranslated regions, continue to be revised as comparative and transcriptomic evidence accumulates. Morgan and colleagues demonstrated hundreds of conserved 3′ ends and predicted 3′UTR extensions that the then-current Ensembl and RefSeq human annotations did not contain [3]. Conclusions that depend on the exact boundaries of a transcript should state the transcript version so a future reader can evaluate them against later editions.

Trusting coordinates from non-reference assemblies. If a collaborator analyzed their own de novo assembly, their coordinates and protein predictions may not correspond to any Ensembl release. Errors in protein coding regions of long-read assemblies can truncate predicted proteins substantially [4]. Before merging such data with reference-anchored results, verify which reference the coordinates refer to and, where possible, re-map their gene content onto a standard release.

Interpreting unexplained identifier gaps as biology. When an enrichment tool reports fewer mapped genes than you supplied, the temptation is to accept the reduced universe as given. Identifier vintage mismatches are a common mechanical cause. Check the tool's supported input types, which vary by design across tools, and re-map against the release your identifiers came from before drawing conclusions.

Confusing identifier versions with statistical reproducibility. Pinning identifiers fixes the annotation layer of reproducibility. It does not fix random seeds, library versions, or batch effects. Version discipline is necessary but not sufficient for a reproducible pipeline, and the limitations section of any analysis should acknowledge both layers. Individual research cases with unusual annotation needs may require consultation with a core facility or an experienced bioinformatician.

Quick Review

1. An Ensembl stable identifier is permanent. The version suffix after the dot counts revisions of that annotated model.
2. Gene IDs (ENSG), transcript IDs (ENST), and protein IDs (ENSP) each carry independent version numbers.
3. The version suffix, the release number, and the genome assembly are three separate layers. Record all three for reproducibility.
4. Versions increment when models change, and models change because annotation improves, as demonstrated by newly validated 3′UTR extensions missing from earlier Ensembl and RefSeq human annotations [3].
5. Archive sites preserve every release, so any published analysis can be checked against the exact snapshot its authors used.
6. Strip version suffixes only for mapping convenience, after archiving the versioned originals.
7. Ensembl version suffixes and RefSeq accession version suffixes are independent systems. ENST00000263735.9 and NM_002354.3 pin the same transcript in two different catalogs [1].

Frequently Asked Questions

What does the number after the dot in an Ensembl ID mean?

It is the version of that specific annotated model. ENST00000263735.9 is the ninth edition of that transcript model, incremented when Ensembl revised the transcript or its protein product [1]. The identifier itself stays stable across releases. Only the suffix moves.

Do I need to keep the version number when mapping gene IDs for enrichment analysis?

Keep it in your archived source data, and strip it only when the mapping step requires an exact match against an unversioned reference. Enrichment tools differ in which input ID types they accept, so version suffixes are often the reason a fraction of identifiers fails to map. Always retain the versioned list as your original record.

Why did my Ensembl gene ID change between releases?

Stable identifiers persist unless the model is merged, split, or discontinued, in which case a genuinely new identifier appears. What changes more often is the version suffix, which increments when the annotated model is revised. Use Ensembl's stable ID history files to trace exactly what happened to each identifier between two releases.

Is an Ensembl version number the same thing as a RefSeq version?

No. They are independent numbering systems from independent curation pipelines. The same biological transcript can be ENST00000263735.9 in Ensembl and NM_002354.3 in RefSeq, with unrelated suffixes [1]. Never infer one version from the other.

How do I get an older Ensembl release for reproducibility?

Use the date-named archive sites, which host every historical release, or pin the release in your programmatic access, for example with the version argument in biomaRt's useEnsembl function. Record the release number, the assembly, and whether identifier versions were retained.

Does the Ensembl version number change when the genome assembly changes?

An assembly change does not by itself increment any version suffix, but it frequently triggers coordinated annotation revisions that do. New assemblies and improved pipelines change gene models, and each changed model receives an incremented version in the next release. Treat an assembly upgrade as a likely annotation event and re-verify your identifiers after it.

Sources

1. Probing the Association of EPCAM Gene Single Nucleotide Polymorphisms with Genetic Disorders
2. PhyreRisk: A Dynamic Web Application to Bridge Genomics, Proteomics and 3D Structural Data to Guide Interpretation of Human Genetic Variants
3. Identification of 3′ gene ends using transcriptional and genomic conservation across vertebrates
4. Errors in long-read assemblies can critically affect protein prediction
5. GeneAutomate: A Browser-Based, Integer-Indexed Platform for Dual-Gene-List Functional Annotation and Interactive Network Visualization