# UniProt Family & Domains vs. Feature Viewer: When to Use Each

The Family & Domains section is the curated, text and table view of what a protein is made of, while the Feature Viewer is the interactive graphical map that plots every annotated feature along the [protein sequence](/blog/guides/protein-sequence). Use Family & Domains when you want to understand a protein and collect domain identifiers for downstream work. Use the Feature Viewer when you need exact positions, overlaps between features, or a picture of how annotations line up along the sequence.

This guide covers both views, compares them on the criteria that decide real choices, walks through worked scenarios from published research, and ends with common mistakes and short answers to frequent questions. If you are new to UniProt, read the orientation section first, because several terms used later are defined there.

## The short answer

![Decision path asking what kind of question you have and routing to Family and Domains, the Feature Viewer, or a set-level tool.](/article-images/illustrations/uniprot-family-domains-vs-feature-viewer-which-view-decision.webp)

Every UniProt Knowledgebase (UniProtKB) entry has two ways to look at the same annotation layer. The Family & Domains section is one of the static, organized blocks on the entry page. It holds curated prose about the protein family, a table of domains and repeats with their amino acid positions, and cross-references to external domain databases such as Pfam and PROSITE. The Feature Viewer is a dynamic canvas that draws all feature types, including domains, active sites, post-translational modifications, topology, variants, and disorder, as tracks across the sequence.

A practical rule of thumb:

1. Ask "what does this protein contain and who says so?" Open Family & Domains.
2. Ask "where exactly is this feature, and does it overlap that variant, that site, or that domain?" Open the Feature Viewer.
3. Ask "how do these annotations compare across dozens or hundreds of proteins?" Leave the per-protein viewer and use a multi-protein tool that reads UniProt features directly.

Both views draw from the same underlying feature table, so they never contradict each other. They answer different questions about the same data.

## How to use UniProt: a two-minute orientation

UniProt is the primary public database of protein sequence and functional information. Its core product, UniProtKB, has two divisions. Swiss-Prot entries are manually reviewed by expert curators. TrEMBL entries are computer-annotated records that hold translations of [nucleotide sequence](/knowledge/molecular-biology/nucleotide-sequence) entries that have not yet been fully integrated into the manually reviewed set [1]. Every entry carries a stable accession, for example P04637 for human p53, and often a mnemonic identifier such as P53_HUMAN.

The entry page is organized into labeled sections:

- Function. What the protein does, catalytic activity, pathway membership, gene ontology terms.
- Names and taxonomy. Recommended and alternative names, organism, gene names.
- Subcellular location and tissue specificity.
- PTM and processing. Signal peptides, chains, modified residues, disulfide bonds.
- Family & Domains. Domains, repeats, regions, compositional bias, family description, and domain database cross-references.
- Sequence. The [amino acid sequence](/blog/guides/amino-acid-sequence), isoforms, and download options.

You can reach an entry three common ways. Search the UniProt website with a protein name, gene symbol, or accession. Retrieve it programmatically through the REST API, for example a request to rest.uniprot.org/uniprotkb/P04637.json returns the entry as JSON. Or follow a cross-reference from another database, such as a Pfam or Ensembl record pointing back to UniProt.

When you search, filter by "Reviewed" if you want Swiss-Prot quality annotation only. This one filter prevents the most common beginner mistake, which is reading an automatic annotation as if a curator had verified it.

## What the Family & Domains section contains

The Family & Domains section answers the question "what conserved building blocks does this protein have, and to which family does it belong?" It contains several distinct blocks.

**Family annotation.** A short curated paragraph describing the protein family, often naming signature motifs, characteristic residues, and the biological role of the family. For a [protein kinase](/knowledge/molecular-biology/protein-kinase), for example, the family text explains membership in the protein kinase superfamily and notes conserved catalytic residues.

**Domains and repeats table.** Rows for each annotated Region, Domain, Repeat, Coiled coil, and Compositional bias, each with a start position, an end position, a description, and an evidence tag. Evidence tags point to the source of the annotation, such as a rule, a curator statement, or a computational prediction, and they follow the Evidence and Conclusion Ontology (ECO) vocabulary.

**Domain database cross-references.** Under the "Family and domain databases" header you find links to Pfam, PROSITE, SMART, CDD, PANTHER, and InterPro, each with the specific accession assigned to this protein. These accessions are the currency of downstream annotation pipelines.

Pfam deserves a word because it appears so often in this section. Pfam is a large collection of protein families, each represented by multiple sequence alignments and hidden Markov models (HMMs), which are statistical models trained to recognize members of the family. Pfam families come with textual descriptions, links to other resources, and literature references, and genome projects use Pfam extensively for large-scale functional annotation of genomic data [1]. The Pfam accessions you see in Family & Domains are the product of running those HMMs against the sequence.

A published study on Hepatitis B virus illustrates the workflow this section supports. The researchers used the UniProt database and the Pfam search tool to identify protein family accession numbers for HBV proteins, then analyzed the locations of rare codon clusters within those annotated protein structures, reporting results for TrEMBL entries [1]. The Family & Domains section and its cross-references were the entry point for that whole analysis.

## What the Feature Viewer shows

The Feature Viewer renders the same underlying feature table as a set of horizontal tracks along the amino acid sequence. Position one sits on the left, the final residue on the right, and every annotation becomes a shape or a label at its coordinates.

Typical track categories include:

- Processing. [Signal peptide](/knowledge/molecular-biology/signal-peptide), propeptide, chain, peptide, transit peptide.
- Regions. Domain, region of interest, repeat, coiled coil, compositional bias.
- Sites. Active site, binding site, glycosylation site, cleavage site.
- Amino acid modifications. Modified residue, cross-link, [disulfide bond](/knowledge/molecular-biology/disulfide-bond-formation-structure-and-function), lipidation.
- Natural variants. Missense variants, disease-associated mutations, polymorphisms.
- Secondary structure and disorder. Helix, strand, and predicted or curated regions of intrinsic disorder.

The viewer is interactive. Click a shape to open a detail panel with the description, evidence, and links to the source database. Zoom into a narrow region to read exact positions. Select a range of residues to see every feature that falls inside it. Toggle feature categories on and off to reduce clutter. For entries with multiple isoforms, an alignment panel shows how features map onto each isoform.

The viewer answers positional questions that the static table handles poorly. Does the phosphorylation site sit inside the kinase domain or outside it? Does the disease-associated variant fall in a disordered region? Does the signal peptide end before the first annotated repeat begins? You can answer all three by looking at the canvas for a few seconds, which would take several minutes of cross-referencing coordinate numbers in a text table.

## Side-by-side comparison

| Criterion | Family & Domains section | Feature Viewer |
|--|--|--|
| Format | Curated text blocks and coordinate tables | Interactive graphical tracks on the sequence |
| Scope shown | Family-level description plus domains, repeats, regions | All feature categories, including sites, PTMs, variants, topology, disorder |
| Primary question | What does this protein contain and to which family does it belong | Where is each feature located and what overlaps it |
| Input effort | Read directly, no interaction needed | Click, zoom, toggle to interrogate positions |
| Position clarity | Precise numbers in a table, hard to see relationships | Positions visible in context, overlaps obvious at a glance |
| Cross-references | Explicit accessions for Pfam, PROSITE, SMART, CDD, PANTHER, InterPro | Individual features link to sources, but database accessions are less prominent |
| Machine reading | Retrieve via REST API as structured fields | Not a tool for scripts, retrieve the same data from the API instead |
| Multi-protein use | One entry at a time, poor for protein sets | One entry at a time, poor for protein sets |
| Best output | Domain accessions for pipelines, prose for manuscripts | Figures, position checks, overlap judgments |
| Weakness | Text and numbers hide spatial relationships | Clutter on long or heavily annotated proteins, no family narrative |

## When to use Family & Domains

Reach for the Family & Domains section in these situations.

**Building background knowledge before you read literature.** The family paragraph compresses what curators learned from many papers into a few sentences. For an unfamiliar protein, this section gives you the vocabulary and the family context you need before reading primary literature.

**Collecting identifiers for a pipeline.** When your analysis needs Pfam or PROSITE accessions as input, the cross-reference block in Family & Domains is the fastest human-readable source. The HBV study described earlier followed exactly this pattern, taking Pfam accession numbers from UniProt entries as the anchor for a downstream structural analysis of rare codon clusters [1].

**Writing a manuscript or a report.** The family description gives you citable, curator-reviewed prose that summarizes domain architecture in conventional terminology. You can adapt it for an introduction section with proper attribution to UniProt and the underlying domain databases.

**Judging annotation quality.** The evidence tags next to each domain tell you whether a curator confirmed the annotation or whether it comes from a computational rule. When two entries disagree, comparing evidence levels in this section often explains why.

**Understanding family membership across homologs.** Because the family text is written at the level of the family, not the individual protein, it generalizes to your homolog of interest.

## When to use the Feature Viewer

Reach for the Feature Viewer in these situations.

**Answering positional questions.** Any question phrased as "where" belongs in the viewer. Where does the catalytic domain start? Where do the repeats sit relative to the transmembrane helices? The table gives coordinates, the viewer gives comprehension.

**Checking overlaps and boundary cases.** Mutational planning, domain boundary cloning, and truncation design all depend on knowing whether two features touch or overlap. Dragging a selection across the sequence reveals every feature in the range instantly.

**Preparing a figure.** A screenshot of the relevant tracks, cleaned up in a vector editor, is a standard way to show a domain map in a talk or a paper. For higher-control needs, export the features and draw your own map.

**Sanity-checking predictions against curation.** If your own predictor flags a domain, a motif, or a disordered region, load the reviewed UniProt entry and check the viewer to see whether the curated annotation agrees. Discrepancies are usually explained by isoform differences or by evidence levels.

**Interrogating variants.** For well-studied human proteins, the variant track is dense. The viewer lets you check whether a mutation of interest falls inside an annotated domain, which is often the first step in interpreting it.

## When to use both together

Most real sessions use both views in a loop. A typical sequence:

1. Search UniProt, filter to Reviewed, open the best-matching entry.
2. Read the Family & Domains text to learn the family and the architecture in words.
3. Copy the Pfam or InterPro accessions for downstream work.
4. Open the Feature Viewer to check positions that matter for your experiment.
5. Toggle off irrelevant categories, for example variants, to see the structural features cleanly.
6. Retrieve the full feature set through the REST API for scripted processing.

The two views are complements, not alternatives. The difference between UniProt Family & Domains and the Feature Viewer is one of presentation and question type, never of underlying data.

## Worked scenarios

### Scenario 1: assigning Pfam families to viral proteins

A virology group studies Hepatitis B virus (HBV), which has nine recognized genotypes plus a putative genotype J. They want to know which protein families appear in the HBV proteome and where in each protein the conserved domains sit, as groundwork for mapping rare codon clusters [1].

The workflow:

1. Search UniProt for the HBV polymerase, surface antigen, core antigen, and X protein, filtering to reviewed entries where available.
2. In Family & Domains, read the family paragraph and note the domain table for each protein.
3. Follow the cross-references to Pfam and record each Pfam accession.
4. Use those accessions as the family labels for the downstream analysis, which located rare codon clusters within the annotated protein structures and reported results for TrEMBL entries [1].

The Family & Domains section did the work here because the goal was family identity and identifiers. The positions mattered too, but the pipeline consumed them as numbers from the feature table, not as a picture.

### Scenario 2: checking whether a mutation falls inside a domain

A lab plans to mutate a serine in a human signaling protein and wants to confirm the residue lies inside the catalytic domain rather than in a flexible linker.

The workflow:

1. Open the reviewed UniProt entry for the protein.
2. In the Feature Viewer, turn on the Domain and Site tracks.
3. Zoom to the region around the target residue.
4. Read the position relative to the annotated domain boundaries directly from the canvas.

This is a pure Feature Viewer task. The Family & Domains table contains the same coordinates, but judging "inside or outside, and is it close to the boundary" from a list of numbers invites errors that a glance at the canvas prevents.

### Scenario 3: comparing feature architecture across a protein family

An omics experiment produces a list of hundreds of proteins. The team wants to see the domain, repeat, disorder, and modification architecture of every protein at once, to spot shared feature patterns and redundancies.

The per-protein Feature Viewer does not scale to this task, since it renders one entry at a time. This is where dedicated set-level tools enter. ProFeatMap, a Python-based web tool, takes a user-defined list of UniProt accession codes, extracts the most important annotated features for each protein from UniProt or InterPro, assigns shapes and colors that can depend on quantitative or [qualitative data](/blog/guides/qualitative-data-analysis-a-practical-guide-for-life-scientists), and sorts the protein list based on homologous feature content [2]. The result is a publication-quality two-dimensional map that lets large protein families be explored and classified by shared feature content, revealing patterns such as feature redundancy that per-protein inspection overlooks [2].

The lesson generalizes. For one protein, the built-in viewer is enough. For a protein set, move to tools that batch-process UniProt features.

## A practical UniProt database tutorial for the entry page

This short tutorial walks a new user through one complete session. The example uses human p53, accession P04637.

1. Go to uniprot.org and type P04637 or "P53_HUMAN" into the search box.
2. On the entry page, confirm the organism and the reviewed status. Swiss-Prot entries display "Reviewed" with a gold badge.
3. Read the Function section to learn what the protein does.
4. Scroll to Family & Domains. Read the family paragraph, then the domain and repeat table. Note the start and end positions of each domain.
5. Open the "Family and domain databases" cross-reference block and list the Pfam, PROSITE, and InterPro accessions. For scripted use, these accessions can be retrieved in bulk through the REST API, for example rest.uniprot.org/uniprotkb/P04637.json returns the full entry as JSON.
6. Open the Feature Viewer on the same page. Turn on the Domain, Site, and Natural variant tracks.
7. Click one domain shape and read the detail panel. Note the evidence tag and any link to the source database.
8. Zoom to a region of interest, select a residue range, and observe which features fall inside.
9. Toggle off the categories you do not need, leaving a clean figure-ready display.
10. Download what you will reuse. The Sequence tab offers FASTA, and the API offers JSON, TSV, and other formats for the feature table.

Ten minutes with this routine covers roughly ninety percent of day-to-day UniProt use. The remaining ten percent, mostly programmatic bulk retrieval and custom filtering, is documented in the official UniProt documentation linked from the site.

## Common Mistakes and Limitations

**Mistake: treating the two views as different data sources.** Family & Domains and the Feature Viewer render the same feature table. If a feature appears in one and not the other, check the category filters in the viewer or the section headers on the page before concluding that the data differ.

**Mistake: reading TrEMBL annotation as curator-verified.** TrEMBL entries carry computer-annotated features. In the HBV workflow cited above, the analyzed entries were TrEMBL records [1], which is common for viral proteins. Automatic annotation is a reasonable starting point, but for any protein whose details will drive an experiment, confirm against the reviewed entry or the underlying domain database.

**Mistake: ignoring evidence tags.** Every feature carries evidence. A domain predicted by a computational rule is not the same claim as a domain confirmed by a curator or an experimental structure. The viewer and the section both expose this, and skipping it produces overconfident conclusions.

**Mistake: confusing family accessions with domain accessions.** A Pfam accession in the cross-reference block names a family-level HMM, not a specific domain instance with coordinates. The coordinates come from the feature table. Conflating the two leads to off-by-hundreds-of-residues errors in scripts.

**Mistake: assuming the viewer shows everything UniProt knows.** Some information, notably deep cross-references, pathway memberships, and much of the family narrative, lives in other sections or in linked databases. The viewer is a spatial rendering, not a complete entry.

**Mistake: using a per-protein viewer for set-level questions.** Viewing hundreds of proteins one at a time hides exactly the cross-protein patterns that matter most in family analysis. Tools built for protein sets, such as ProFeatMap, exist for this reason and extract the same UniProt or InterPro features into a single customizable map [2].

**Limitation: feature coordinates depend on the sequence version.** When an entry's sequence is updated, coordinates can shift. Record the entry version number and date alongside any coordinates you quote, especially in long-running projects.

**Limitation: automatic domain predictions have boundaries with uncertainty.** HMM-based methods such as Pfam define domain boundaries statistically, and profiles from different databases can disagree by a few residues at either end. When exact boundaries matter, for example for cloning a domain, compare multiple sources and, where possible, a structural model.

Individual proteins with unusual biology or conflicting annotations deserve review by a specialist or by correspondence with the UniProt help desk, since an entry summarizes a large literature and cannot substitute for domain expertise on a specific system.

## Reading evidence tags the way curators intend them

The evidence tags attached to every domain, site, and region in both Family & Domains and the Feature Viewer are the single most underused piece of information on the entry page. Most users scan the feature names and coordinates and never ask who supplied the claim. Building the habit of reading evidence changes how you weight every downstream decision.

UniProt records evidence using the Evidence and Conclusion Ontology, and the practical effect is that every feature falls somewhere on a spectrum from directly measured to purely inferred. At the strongest end sit features supported by experimental characterization, such as a catalytic residue identified by mutagenesis or a domain whose boundaries come from a solved structure. Below that sit curator statements assembled from literature, then inferences by similarity from homologs in other organisms, and finally computational predictions produced by rules, signatures, or statistical models. The exact tag text varies by feature, but the ranking logic stays constant.

Three habits make this usable in daily work:

1. **Click the evidence icon before quoting a position.** The detail panel behind each feature, in the viewer or the table, names the source. A domain drawn from a structural analysis and a domain drawn from a sequence profile look identical as colored shapes, but they support very different claims about boundary precision.
2. **Sort your expectations by evidence class.** If you are designing a truncation construct around a computationally predicted domain, treat the boundary as approximate and build in margin. If the same boundary comes from a structure, you can design primers directly at the annotated edge.
3. **Record evidence alongside coordinates in your notebook or pipeline output.** A table of positions without evidence labels becomes unreadable six months later, when you no longer remember which numbers were curator confirmed and which came from a prediction.

The reviewed versus unreviewed distinction interacts with evidence in a way that surprises newcomers. A Swiss-Prot entry is curated, but that does not make every feature experimental. Curators import predictions too, and they label them as such. Conversely, a TrEMBL entry contains almost entirely automatic annotation, yet some of its features can trace back through automated rules to high-quality signatures from databases such as Pfam and PROSITE. The HBV codon-cluster study discussed in this article worked from TrEMBL entries and still produced a coherent analysis, because the Pfam-based family assignments behind those entries were statistically well founded even though no curator had touched each record [1]. The lesson is not that unreviewed data are worthless. The lesson is that the evidence tag, not the gold badge, tells you how much weight each individual feature can carry.

A simple exercise cements the habit. Open any reviewed human kinase entry, find three features of the same type, for example three binding sites, and read the evidence behind each. You will typically find that some trace to specific experiments and others to similarity or prediction. Once you have seen that spread inside a single well-studied entry, you will never again treat a feature table as a uniform block of equally reliable facts.

## How the domain databases behind the cross-references differ

The "Family and domain databases" block lists several resources, and beginners often treat their accessions as interchangeable labels for the same thing. They are not. Each database answers a slightly different question, and knowing the differences tells you which accession to collect for which purpose.

**Pfam** organizes protein families as multiple sequence alignments and hidden Markov models, which are statistical models trained to recognize family members. Pfam families carry textual descriptions, links to related resources, and literature references, and genome projects rely on Pfam extensively for large-scale annotation of newly sequenced organisms [1]. When your pipeline needs a stable, widely cited family identifier, the Pfam accession is usually the right choice, and it is the accession the HBV workflow anchored its analysis to [1].

**PROSITE** specializes in short signatures. Its patterns behave like sequence motifs, asking whether a small stretch of residues matches a defined pattern, and its profiles extend that idea to longer regions. Where you care about a catalytic triad, a glycosylation consensus, or another compact motif, the PROSITE annotation often pinpoints residues more tightly than a family-level model.

**SMART** concentrates on domains found in multidomain proteins, with particular strength in signaling, extracellular, and regulatory architectures. If your protein is a mosaic of repeats, linkers, and interaction modules, the SMART annotation frequently decomposes it more finely than other sources.

**CDD** is maintained at NCBI and combines curated domain models with imported alignments, which makes it a useful cross-check when two other databases disagree about a boundary.

**PANTHER** approaches families from a phylogenetic angle, organizing proteins into families and subfamilies with an emphasis on evolutionary relationships and inferred function. When the question is which subtype of a family your protein belongs to, PANTHER annotations are the most informative of the set.

**InterPro** is the integrator. It groups signatures from the member databases into a single nonredundant classification, so one protein often carries one InterPro accession that unifies several member database hits. For reporting, an InterPro accession is often the cleanest single identifier, while the member database accessions underneath it preserve the fine detail.

Two practical rules follow. First, for a manuscript, report the InterPro accession plus the most specific member database accession relevant to your claim, rather than a wall of five identifiers. Second, for a pipeline, choose one source and stay with it across your whole protein set. Mixing accessions from different databases mid-analysis produces inconsistent granularity, where one protein's "domain" spans four hundred residues and the next one's spans sixty, purely because of database philosophy rather than biology.

## Deep walkthrough: one protein, both views, every decision

To show the two views cooperating on a protein with genuinely mixed architecture, walk through human p53, accession P04637, which was introduced earlier in this guide. p53 is an ideal teaching protein because its features separate cleanly into a structured core flanked by regions that behave very differently.

Start in Family & Domains. The family paragraph identifies p53 as a transcriptional regulator involved in the cellular response to stress, and places it in its protein family with the vocabulary that the primary literature uses. The domain and region table then shows a pattern worth internalizing: a central structured DNA-binding region, an oligomerization region toward the C-terminus, and extensive stretches annotated as disordered toward both ends. Note the evidence pattern as you read. The DNA-binding region carries annotation backed by structural and experimental work, while the disordered stretches rest on prediction and biophysical characterization of their behavior rather than a single solved fold.

Now open the Feature Viewer and turn on the Domain, Site, Amino acid modification, Natural variant, and Disorder tracks. Four positional facts become visible within seconds, none of which are obvious from the table:

1. **The missense variant track is densest across the central DNA-binding region.** Missense variants cluster where structure matters, because substitutions there disrupt a folded domain. A glance at the canvas turns that observation from a statistic into a spatial fact you can point at in a talk.
2. **The modification track concentrates in the disordered terminal regions.** Phosphorylation and other modification sites sit overwhelmingly outside the structured core, which is the classic arrangement for regulatory modifications on intrinsically disordered segments. If you were mapping which residues to mutate to study regulation, the viewer tells you instantly that the regulatory chemistry lives in the flexible ends.
3. **The disorder track and the variant track anticorrelate.** Variants crowd the structured core; modifications crowd the disordered flanks. Seeing the two tracks together produces a hypothesis about functional constraint that neither track alone states.
4. **The structured core has crisp boundaries relative to everything else.** Any construct-design decision, such as expressing the DNA-binding region on its own, can be read directly off the canvas with the flanking disorder visibly excluded.

Now close the loop with the three-step routine. The family paragraph gave you the words for the manuscript introduction. The cross-reference block gave you accessions for a pipeline. The viewer gave you the four positional judgments above. At no point did the two views disagree, because they render one feature table, but each answered questions the other handles badly. This is the pattern to reproduce for any protein you study: narrative and identifiers first from Family & Domains, spatial reasoning second from the viewer, and both grounded in the evidence tags you checked along the way.

## Isoforms, sequence versions, and why your numbers do not match the paper

![Flowchart branching through isoform mismatch, mature chain versus precursor numbering, and sequence version drift to explain a coordinate mismatch.](/article-images/illustrations/uniprot-family-domains-vs-feature-viewer-numbering-mismatch-flow.webp)

Nothing erodes trust in an annotation faster than a residue number that will not reproduce. When a position you read in a publication does not line up with the Feature Viewer, the cause is almost always one of three numbering mismatches, and each has a straightforward check.

**Isoform mismatch.** Many UniProt entries describe several isoforms produced by [alternative splicing](/blog/guides/alternative-splicing). The canonical sequence, shown by default in the viewer, is one representative isoform, and the remaining isoforms are listed in the Sequence section with their own identifiers built from the accession, in the style of P04637-1 for the canonical human p53 sequence. If a paper numbered residues on a noncanonical isoform, its numbers can differ from the viewer by the length of the alternative exon. The fix is to open the isoform alignment panel in the viewer and confirm which isoform the entry numbers refer to, then restate the paper's position in canonical numbering before comparing.

**Mature chain versus precursor numbering.** Secreted proteins are annotated with a signal peptide, and the mature protein circulates without it. A residue numbered 34 in the mature protein may sit around residue 60 in the precursor, depending on the signal peptide length shown in the Processing track. UniProt positions are given in precursor coordinates. Whenever a literature position refers to a mature chain, add the length of the annotated signal peptide or propeptide before comparing. The Processing track in the viewer shows exactly where each cleavage occurs, which is one of the clearest cases where the graphical view prevents an arithmetic error.

**Sequence version drift.** An entry's sequence can be updated, and when that happens downstream coordinates can shift. This is why the troubleshooting advice elsewhere in this guide tells you to record entry and sequence versions with every quoted coordinate. If a discrepancy appears against an older paper, check whether the entry has been updated since publication and whether the region in question was affected.

A fourth, rarer cause is annotation-specific numbering, for example a domain database that numbers within its own alignment rather than in full-protein coordinates. If none of the three checks above resolves a mismatch, verify the position against the cross-referenced domain database record before concluding that anyone made an error.

The general discipline is simple. Treat a bare residue number as incomplete data. A complete positional claim states the accession, the isoform, the numbering convention, and the entry version. With those four pieces, any position can be rechecked by anyone, in either view, years later.

## From Feature Viewer to data table: programmatic retrieval step by step

The Feature Viewer is for eyes, not scripts. Everything it draws, however, comes from the entry's feature table, and that table is available through the REST API in machine-readable form. This section walks through retrieving and parsing features, using the same p53 accession, P04637, used throughout this guide.

**Step 1: fetch the entry as JSON.** A single request returns the full record:

```
curl -s "https://rest.uniprot.org/uniprotkb/P04637.json" > p04637.json
```

The response is one JSON object containing the sequence, the cross-references, and, crucially, a features array in which every element carries a feature type, a description, a location with begin and end positions, and evidence.

**Step 2: filter the feature types you need.** Each feature in the array carries a type field whose values correspond to the categories you toggle in the viewer, such as domain, region, site, modified residue, natural variant, and disordered region. A jq one-liner extracts domains with their coordinates:

```
jq '.features[] | select(.type == "Domain") | {description: .description, start: .location.start.value, end: .location.end.value}' p04637.json
```

This output is the machine-readable equivalent of the domain table in Family & Domains. Anything you can judge visually in the viewer, such as whether a site overlaps a domain, becomes a comparison of two integer ranges in a script.

**Step 3: pull the domain database cross-references.** The cross-reference list in the JSON holds the Pfam, PROSITE, SMART, CDD, PANTHER, and InterPro accessions shown in the Family & Domains block, each linked to the entry. Filter that list the same way to collect identifiers for a pipeline, exactly as the HBV study collected Pfam accessions as anchors for its codon-cluster analysis [1].

**Step 4: use the search endpoint for bulk work.** For a set of accessions or a whole taxonomic slice, the search endpoint returns tabular output with chosen fields, which avoids fetching full JSON for hundreds of entries:

```
curl -s "https://rest.uniprot.org/uniprotkb/search?query=accession:P04637&format=tsv&fields=accession,id,ft_domain,xref_pfam"
```

The fields parameter mirrors the feature categories: feature-type fields return the coordinate text for each category, and cross-reference fields return the external accessions. Building one query that returns every protein in your set with its domains and Pfam hits replaces an afternoon of clicking with a single reproducible command.

**Step 5: reconcile the table with the viewer.** Before trusting a parsed table, spot-check two or three features against the interactive view. This catches parsing slips, such as reading the wrong location field, and it also catches genuine surprises, such as a feature present in the API but filtered out of your viewer display.

Two cautions apply. First, feature types in the API are more granular than the viewer's track labels, so group them deliberately when summarizing. Second, remember the reproduction discipline from the isoform section: capture the entry version with the data, because a snapshot taken today and a snapshot taken after a sequence update can differ. A script that records its retrieval date and the entry version alongside the extracted features costs one extra column and prevents most reproducibility arguments.

With this pipeline in place, the division of labor becomes explicit. The viewer answers spatial questions during analysis and produces figures; the API produces the coordinates the viewer is drawing; set-level tools consume both. This is also the point where per-protein inspection stops scaling, which is exactly the problem the ProFeatMap tool was built to address, by extracting annotated features for a user-defined list of UniProt accessions into a single sortable two-dimensional map [2].

## Troubleshooting: eight problems you will hit and how to fix them

**1. A feature you know exists does not appear in the viewer.** First check the category toggles; the most common cause is a switched-off track. Second, check the isoform selector, because a feature annotated on one isoform may be absent or shifted on another. Third, confirm you are on the entry you think you are, since near-identical gene names across species lead to the wrong record more often than users admit.

**2. The domain cross-reference block is empty or thin.** This is normal for many TrEMBL entries and for proteins whose signatures have not been computed or matched. Work from the reviewed entry of the closest homolog, or run the sequence against the domain databases directly, and treat the result as prediction-level evidence regardless of how confident the score looks.

**3. The viewer is slow or cluttered on a long, heavily annotated protein.** Turn off tracks you are not using, starting with natural variants on well-studied human proteins, which can carry hundreds of entries. Zoom to the region of interest before enabling fine-grained tracks such as sites and modifications. The canvas is meant to be interrogated in slices, not absorbed whole.

**4. Your coordinate does not match the literature.** Work through the numbering checks from the isoform section: isoform mismatch, mature chain versus precursor numbering, and sequence version drift. Nine of ten mismatches resolve at one of those three steps.

**5. Two proteins in your set disagree about a shared domain.** Check the evidence tags first. A difference between a curator-confirmed boundary and a predicted one, or between signatures from two databases with different modeling philosophies, explains most conflicts. Where boundaries matter operationally, for example in cloning, take the conservative intersection and verify against a structural model where one exists.

**6. A script returns features that look shifted.** Confirm you are parsing the correct location fields and that you have not mixed inclusive and exclusive coordinate conventions between your own code and the API output. Then spot-check against the viewer as described in the programmatic section.

**7. The variant track looks empty on a protein you know has variants.** Natural variant annotation concentrates in reviewed entries and in proteins with active literature. A sparse track on an unreviewed entry reflects curation status, not biology. Cross-check a disease database through the entry's cross-references before concluding that variation is absent.

**8. The entry changed since you last looked.** UniProt maintains version history for entries. If a collaborator's older screenshot or table disagrees with today's page, compare entry versions and dates before debating biology. Most such disagreements are version artifacts, not annotation reversals.

A pattern runs through all eight fixes: the problem is almost never the data, it is the presentation layer, the numbering convention, or the evidence class. Diagnosing at that level turns frustration into a routine check.

## Common misconceptions that survive into published papers

**Misconception: reviewed means every feature is experimentally proven.** Review status describes the curation process, not the evidence behind each individual feature. A reviewed entry mixes experimental confirmation, curator synthesis from literature, similarity transfer, and computational prediction, all distinguished by evidence tags. Quoting a predicted domain as structurally established, on the strength of the reviewed badge alone, is a classification error that evidence-reading prevents.

**Misconception: a predicted domain is a structure.** A domain annotation asserts that a region belongs to an evolutionary family with shared descent and usually shared function. It does not assert that the region folds independently, adopts a particular conformation, or has precise boundaries. For structural claims, cite a structure or a model, not the domain table.

**Misconception: agreement across databases is independent confirmation.** InterPro integrates member databases, and several member models descend from related alignments and similar methods. Two signatures agreeing on a region is reassuring, but it is weaker than two genuinely independent lines of evidence, such as a signature match plus experimental characterization. Weight agreement accordingly, especially for boundary precision.

**Misconception: automatic annotation is useless.** Unreviewed records carry computer-annotated features, and for large-scale questions, especially in organisms and viruses where reviewed entries are scarce, they are the only practical substrate. The HBV analysis in this article ran over TrEMBL records precisely because viral proteomes live largely in that division [1]. The correct stance is calibrated use: automatic annotation supports pattern-level and set-level claims, while residue-level experimental decisions deserve confirmation against reviewed entries or source databases.

**Misconception: the Family & Domains table lists everything worth knowing about the protein's architecture.** The table covers domains, repeats, regions, coiled coils, and compositional bias, but sites, modifications, variants, and topology live in other sections and appear only in the viewer. A protein can look architecturally simple in Family & Domains and be densely decorated once the site and modification tracks are visible.

**Misconception: viewing many proteins one at a time is a legitimate set-level method.** Serial inspection hides exactly what family analysis exists to find: shared feature content, redundancy, and systematic differences between groups. Tools designed for sets, such as ProFeatMap, exist because this misconception is common and costly; ProFeatMap takes a user-defined list of UniProt accessions, extracts the important annotated features from UniProt or InterPro, assigns shapes and colors optionally tied to quantitative or qualitative data, and sorts the list by homologous feature content into a publication-quality map [2]. No amount of per-protein clicking substitutes for that cross-protein view.

**Misconception: the accession alone makes a positional claim reproducible.** As covered in the isoform section, reproducibility requires accession, isoform, numbering convention, and entry version. Papers that quote only an accession and a residue number invite the very mismatches that troubleshooting section four describes.

## Five practical analysis patterns that combine both views

**Pattern 1: variant interpretation for a human protein.** Start with Family & Domains to learn which region the gene's domains occupy and to collect the relevant InterPro accession. Then move to the viewer, enable the natural variant and domain tracks, and locate each variant of interest relative to domain boundaries. A variant inside a structured catalytic domain carries different prior weight than one in a disordered tail, and the viewer makes that classification a ten-second judgment. Finish by exporting the underlying variant features through the API if the set is large.

**Pattern 2: construct design for recombinant expression.** Read the family paragraph to understand which region carries the activity you want. In the viewer, enable domain, region, topology, and disorder tracks, then drag a selection across your candidate construct boundaries and read every feature the selection touches. Disordered flanks, transmembrane helices, and truncation-sensitive oligomerization regions all announce themselves in the selection. Record the final boundaries with their evidence classes, and keep the entry version in your [lab notebook](/knowledge/molecular-biology/lab-notebook).

**Pattern 3: antibody epitope planning.** Effective epitopes usually sit in accessible, unique, nonconserved regions. The viewer supports all three filters: topology and region tracks flag membrane-spanning and signal segments, the domain tracks show where conservation-driven family models place their signatures, which approximates where homologous proteins will cross-react, and the modification track warns of residues whose chemistry may matter. Family & Domains contributes the family narrative that explains why a given domain is a poor epitope choice across a protein family.

**Pattern 4: mass spectrometry peptide mapping.** When interpreting which peptides were observed or which modified residues were quantified, map each peptide onto the viewer. A peptide falling inside a folded domain, inside a repeat, or across a cleavage site annotation changes how you interpret coverage and modification stoichiometry. The site and amino acid modification tracks provide the residue-level context that a coverage plot lacks.

**Pattern 5: comparative analysis across a viral or taxonomic group.** For a viral proteome, collect family assignments through the UniProt and Pfam cross-references as the HBV study did, using those accessions as the stable labels that make isolates comparable [1]. Then, if the goal expands from family labels to whole-protein feature architecture across many proteins, move to set-level tooling. ProFeatMap was applied to exactly this kind of question, building a two-dimensional feature map for a user-defined accession list and sorting proteins by shared feature content so that redundancies and shared architectures become visible at a glance [2]. The progression from per-protein views to a set-level map mirrors the progression from hypothesis formation to classification.

Each pattern uses Family & Domains for identity and language, the viewer for spatial judgment, and the API or a set-level tool when scale demands it. Once you have run each pattern once, the choice of view stops being a debate and becomes a reflex tied to the question in front of you.

## A reproducibility checklist for any UniProt-derived claim

Every claim in a manuscript, thesis, or internal report that rests on UniProt annotation should survive the following checklist. Run it before submission, not after a reviewer asks.

1. **State the accession, not just the gene name.** Gene symbols collide across species and change over time. The accession is the stable key.
2. **State the entry version and the retrieval or verification date.** Entries update, and coordinates can move with sequence updates.
3. **State the isoform.** If you used the canonical sequence, say so. If a paper's numbering referred to another isoform, say which one.
4. **State the numbering convention.** Precursor versus mature chain numbering is the classic silent failure in secreted and processed proteins.
5. **Record the evidence class for each quoted feature.** One word per feature, experimental or curated or similarity or predicted, is enough to keep conclusions honest.
6. **Record the domain database accessions separately from UniProt coordinates.** A Pfam accession names a family-level model, while the UniProt feature table gives the matched positions on your protein; keeping the two explicit prevents the conflation error described earlier in this guide.
7. **Snapshot your programmatic retrieval.** Save the raw JSON or TSV you parsed, with the retrieval command in a methods note. A saved response is reproducible; a memory of what the viewer showed is not.
8. **Note any cross-checks performed.** If you confirmed a predicted boundary against a structure or a second database, record that check and its outcome.

This checklist costs minutes and resolves the majority of annotation disputes before they start. It also disciplines your own thinking: assembling item five alone, evidence class for each feature, frequently reveals that a planned conclusion rests on predictions stacked in series rather than on any confirmed fact.

## A question-first decision rule you can memorize

The comparison table earlier in this article lists criteria side by side, but daily work needs something shorter. Compress the whole guide into question phrases and their answers:

- "What is this protein and what family does it belong to?" Family & Domains, family paragraph.
- "Give me the identifiers for my pipeline." Family & Domains, cross-reference block, or the API for bulk retrieval [1].
- "Where exactly is feature X relative to feature Y?" Feature Viewer, with the relevant tracks enabled.
- "Does my mutation or peptide fall inside that domain?" Feature Viewer, zoom and select.
- "Can I trust this boundary for cloning?" Evidence tags in either view, then a structural cross-check.
- "Why do these numbers not match the paper?" Isoform, mature chain, and version checks, not the viewer.
- "What does my set of two hundred proteins share?" Neither built-in view; a set-level tool such as ProFeatMap [2].
- "What do I cite?" The entry, by accession and version, plus the source domain database for any central domain claim.

Notice that only two of the eight answers are "open one view and look." Most real questions route through evidence reading, numbering discipline, or scale-aware tooling, which is why this guide spends more pages on those habits than on the views themselves. The views are easy; using them correctly is a matter of asking the question precisely enough that the right tool is obvious.

## A 45-minute onboarding exercise for a new student

Hand this exercise to a rotation student, a new team member, or yourself a year ago. It exercises every habit in this guide on a single protein, human p53, P04637, and produces a short written deliverable that can be checked in minutes.

**Part 1, orientation, ten minutes.** Open the entry, confirm the reviewed status and organism, and read the Function section. Write two sentences describing the protein without copying the entry text verbatim.

**Part 2, family and identifiers, ten minutes.** Read the Family & Domains family paragraph. List the domain and region table rows with their start and end positions. From the cross-reference block, record the Pfam and InterPro accessions. Then fetch the same two identifiers from the API with the search endpoint and fields shown in the programmatic section, and confirm they match what the page displayed.

**Part 3, spatial reasoning, ten minutes.** In the Feature Viewer, enable the domain, site, modification, variant, and disorder tracks. Answer three questions in writing: where do the variants concentrate, where do the modifications concentrate, and what is the relationship between the disordered regions and each of those two tracks. Give the evidence class you would assign to the disordered-region annotation.

**Part 4, failure modes, ten minutes.** Deliberately break things and diagnose. Toggle every track off and find a known domain, then explain why it disappeared. Check whether the entry lists isoforms and identify the canonical one. Note the entry version. Simulate the mature-chain numbering trap by finding any processing feature that would shift residue numbers between precursor and mature protein.

**Part 5, scale check, five minutes.** Consider a hypothetical set of twenty homologs. Write one sentence explaining why clicking through twenty viewers is the wrong approach, and name the category of tool that handles the set, citing the approach of extracting features for a user-defined accession list into a sortable map [2].

The deliverable fits on one page, and a supervisor can audit it against the entry in five minutes. Students who complete it rarely make the mistakes collected in the troubleshooting and misconceptions sections, because they have triggered each one deliberately in a setting where the cost is a redo rather than a flawed experiment. For groups that onboard people regularly, swapping in a different protein each cycle keeps the exercise fresh while the structure, and the habits it installs, stay constant.

## Frequently Asked Questions

### Is the Feature Viewer just a picture of the Family & Domains section?

No. The viewer draws every feature category, including sites, modifications, variants, topology, and disorder, many of which live outside Family & Domains. Family & Domains adds the family narrative and the domain database cross-references that the viewer does not emphasize.

### Can I get UniProt features programmatically?

Yes. The UniProt REST API returns full entries and individual feature types in JSON, TSV, and other formats. Query rest.uniprot.org/uniprotkb/ with the accession of interest, and add the format extension you need.

### Do Family & Domains and the Feature Viewer show different data?

No. Both render the same underlying UniProtKB feature table. They differ in presentation and in which questions they answer well.

### Which view should I cite in a paper?

Cite the UniProt entry itself, by accession and version, regardless of which view you used. If a domain assignment is central to your argument, cite the source database as well, such as Pfam or PROSITE.

### How do Pfam accession numbers relate to UniProt domains?

Pfam defines protein families with hidden Markov models built from multiple sequence alignments, and UniProt cross-references match each protein to the Pfam accessions its sequence hits [1]. The Pfam accession names the family, while UniProt features give the matched positions.

### Can I compare many proteins at once in the Feature Viewer?

Not practically, since it renders one entry at a time. For protein sets, use a dedicated tool such as ProFeatMap, which builds a customizable two-dimensional feature map for a user-defined list of UniProt accessions [2].

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Is the Feature Viewer just a picture of the Family & Domains section?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. The viewer draws every feature category, including sites, modifications, variants, topology, and disorder, many of which live outside Family & Domains. Family & Domains adds the family narrative and the domain database cross-references that the viewer does not emphasize."
      }
    },
    {
      "@type": "Question",
      "name": "Can I get UniProt features programmatically?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. The UniProt REST API returns full entries and individual feature types in JSON, TSV, and other formats. Query rest.uniprot.org/uniprotkb/ with the accession of interest and the format extension you need."
      }
    },
    {
      "@type": "Question",
      "name": "Do Family & Domains and the Feature Viewer show different data?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Both render the same underlying UniProtKB feature table. They differ in presentation and in which questions they answer well."
      }
    },
    {
      "@type": "Question",
      "name": "Which view should I cite in a paper?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Cite the UniProt entry itself, by accession and version, regardless of which view you used. If a domain assignment is central to your argument, cite the source database as well, such as Pfam or PROSITE."
      }
    },
    {
      "@type": "Question",
      "name": "How do Pfam accession numbers relate to UniProt domains?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Pfam defines protein families with hidden Markov models built from multiple sequence alignments, and UniProt cross-references match each protein to the Pfam accessions its sequence hits. The Pfam accession names the family, while UniProt features give the matched positions."
      }
    },
    {
      "@type": "Question",
      "name": "Can I compare many proteins at once in the Feature Viewer?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Not practically, since it renders one entry at a time. For protein sets, use a dedicated tool such as ProFeatMap, which builds a customizable two-dimensional feature map for a user-defined list of UniProt accessions."
      }
    }
  ]
}
</script>

## Sources

1. [Bioinformatic Identification of Rare Codon Clusters (RCCs) in HBV Genome and Evaluation of RCCs in Proteins Structure of Hepatitis B Virus.](https://pubmed.ncbi.nlm.nih.gov/27882067/)
2. [ProFeatMap: a highly customizable tool for 2D feature representation of protein sets.](https://pubmed.ncbi.nlm.nih.gov/36936371/)