How to Predict T-Cell Epitopes and MHC Binding with NetMHCpan and IEDB

To predict T-cell epitopes, submit your antigen sequence to NetMHCpan-4.1 for MHC class I or NetMHCIIpan-4.3 for class II, choose a small HLA allele panel instead of every allele, set the peptide length the class supports, and filter on percentile rank: strong binders sit below 0.5% rank for class I.

This is the step where most student vaccine-design projects stall. The B-cell stage is forgiving, because you submit one sequence and read one score column. The T-cell stage is not. You submit the same protein, the server asks you for alleles and peptide lengths that nobody explained, and you get back a table with thousands of rows in which almost every peptide looks like it binds something. The failure is never the server. It is that percentile rank, allele choice, and peptide length are three separate decisions, and skipping any of them produces a table you cannot defend at a viva. This guide covers all three, with a worked example and the errors you will actually hit.

On this page

• What is a T-cell epitope predictor actually predicting?
• Which HLA alleles should you run, and how many?
• Do class I and class II need different servers and lengths?
• How do you read percentile rank versus predicted affinity?
• How do you run the prediction, step by step?
• How do you turn thousands of rows into a shortlist?
• What goes wrong, and how do you fix it?
• What comes after the shortlist?
• Frequently asked questions

What is a T-cell epitope predictor actually predicting?

It is predicting presentation, not immunogenicity. A T-cell epitope is a short peptide that has been cut out of a protein inside a cell and loaded into the groove of an MHC molecule so that a T-cell receptor can see it. NetMHCpan and its relatives model that loading step. They tell you how likely a given peptide is to be presented by a given MHC allele. They do not tell you whether a T cell exists in a patient that will respond to it.

That distinction changes how you read your output. A high-ranking peptide is a candidate for experimental testing, not a validated epitope, and your write-up should say so. It also explains why allele choice matters so much: presentation is allele-specific by definition, so a peptide is never a “predicted epitope” on its own. It is a predicted epitope for a named allele, and reporting it without the allele is meaningless.

The current generation of these tools is described in Reynisson and colleagues, NetMHCpan-4.1 and NetMHCIIpan-4.0: improved predictions of MHC antigen presentation by concurrent motif deconvolution and integration of MS MHC eluted ligand data, published in Nucleic Acids Research in 2020. The key methodological point for a student is that these networks are trained on two kinds of data at once: classical binding affinity measurements and mass-spectrometry eluted ligands, which are peptides physically recovered from MHC molecules on real cells. That is why the output has two score families, and why the eluted-ligand score is the one the servers now put first.

Which HLA alleles should you run, and how many?

Run a small, justified panel. Not every allele, and not one.

Running every available allele is the most common mistake and it is self-defeating. NetMHCpan-4.1 covers 170 MHC molecules with binding affinity data and 177 with eluted ligand data, spanning human HLA-A, B, C and E plus mouse, cattle, primate, swine, equine and dog molecules. If you run all of them, every peptide in your protein will be a strong binder for something, your table will have tens of thousands of rows, and you will have learned nothing. The server itself caps this: a maximum of 20 MHC types is allowed per submission.

The defensible approach is a supertype or population-coverage panel of roughly six to twelve alleles, chosen for a stated reason. Two reasons are acceptable in a student project:

1. Population coverage. Pick alleles that are common in the population your vaccine is aimed at. Frequencies by country and ethnic group are catalogued in the Allele Frequency Net Database, which is the source to cite for this choice. Look up your target population, take the most frequent alleles at A, B and DRB1, and record the frequencies you used in your methods section.
2. Supertype representation. HLA alleles cluster into supertypes with overlapping peptide-binding preferences, so a handful of representative alleles approximates much broader coverage. If you use this route, name the supertype scheme you followed and cite it.

Either way, write the justification down before you run anything. The panel is a methods decision, and an examiner will ask why those alleles and not others. “They were the default” is not an answer.

Do class I and class II need different servers and lengths?

Yes, and this is where silent errors creep in. MHC class I presents short peptides to CD8+ cytotoxic T cells; class II presents longer ones to CD4+ helper T cells. Different groove, different length, different server, different thresholds. A vaccine construct usually needs both, so you will run two predictions, not one.

The practical differences, taken from the official documentation of each tool:

Note the threshold difference in the third and fourth rows. Class II thresholds are looser (1% and 5%) than class I (0.5% and 2%) because class II binding is genuinely less sharply defined: the groove is open at both ends, so the same core can be presented in several registers. If you apply the class I cutoff to class II output you will throw away real candidates, and if you apply the class II cutoff to class I output you will keep noise. Use each tool’s own default.

Both DTU servers are also reachable through the Immune Epitope Database and Analysis Resource, which wraps them in a single interface alongside processing and immunogenicity predictors. The IEDB documentation states that its recommended method for class I currently uses NetMHCpan 4.1 EL for epitope prediction and NetMHCpan 4.1 BA for binding prediction across all alleles, so you are running the same underlying network either way. Use the DTU server when you want the raw output columns and the IEDB when you want the surrounding toolset.

How do you read percentile rank versus predicted affinity?

Filter on percentile rank. Report affinity as supporting information.

Your output carries two different kinds of number and students routinely filter on the wrong one. The raw score is a network output whose scale is not comparable between alleles. The percentile rank places your peptide against a background distribution, which is what makes alleles comparable to each other.

The NetMHCpan-4.1 output format documentation defines the rank column as the “Rank of the predicted binding score compared to a set of random natural peptides” and notes that it “is not affected by inherent bias of certain molecules towards higher or lower mean predicted affinities”. The same page then gives the advice that settles the question: “We advise to select candidate binders based on %Rank rather than Score.” The IEDB documentation describes its percentile rank the same way, generated by comparing the peptide’s IC50 against a set of random peptides from SWISS-PROT, and states plainly that a small numbered percentile rank indicates high affinity.

So the rule is: a lower rank is better, and the rank is what you filter on. A rank of 0.1 means the peptide scored in the top 0.1% of random natural peptides for that allele. That is a strong binder regardless of which allele produced it, which is exactly the property you need when you are comparing candidates across a panel.

Predicted affinity still has a use. It is expressed in nanomolar IC50, and the IEDB documentation gives the conventional interpretation: below 50 nM is high affinity, below 500 nM is intermediate, and below 5,000 nM is low. Quote these figures for your shortlisted peptides in the results table, because reviewers expect them, but do not use them as your primary filter across alleles.

The columns you will see, and which ones matter

A NetMHCpan-4.1 output row contains Pos, HLA, Peptide, Core, Of, Gp, Gl, Ip, Il, Icore, Identity, Score_EL, Rnk_EL and BindLevel. For a first project, four of those carry your analysis: HLA (which allele), Peptide (the sequence), Rnk_EL (your filter column), and BindLevel (the SB or WB flag the server has already applied for you). Pos gives you the start position in the parent protein, which you need later when you check whether your epitopes overlap. The Core and offset columns describe the binding register and matter more for class II than class I.

How do you run the prediction, step by step?

Work through it on a real antigen. Take the SARS-CoV-2 spike glycoprotein, UniProt P0DTC2, a 1,273-residue surface protein. It is a good teaching example because it is well studied, so you can sanity-check your output against published epitopes.

1. Get a clean FASTA. Download the canonical sequence from UniProt. Open it in a plain-text editor and confirm it contains only the 20 standard one-letter residue codes. Both servers accept A, C, D, E, F, G, H, I, K, L, M, N, P, Q, R, S, T, V, W, Y and X for unknown, and nothing else. Gap characters, digits, asterisks and the ambiguity codes B, Z, J and U will be rejected.
2. Decide the class. For CD8+ epitopes go to NetMHCpan-4.1. For CD4+ helper epitopes go to NetMHCIIpan-4.3. Run both if your construct needs both, and keep the two result sets in separate files from the start.
3. Set the peptide length. For class I, start with 9-mers, which is the default digestion length and the dominant length in real class I ligands. Add 10-mers on a second pass if you want more candidates. For class II, keep the 15-mer default.
4. Enter your allele panel. Paste the six to twelve alleles you justified earlier, using the exact nomenclature the server’s own dropdown shows. Do not exceed 20 alleles for class I or 15 for class II.
5. Leave the thresholds at their defaults. 0.5% and 2% for class I, 1% and 5% for class II. Changing them is a decision you must justify; keeping them is the citable choice.
6. Submit, then save the raw output before touching it. Keep the unmodified server output as a file, and do your filtering on a copy. You will need the original when a supervisor asks what you started from.

What a submission of this size actually produces

Work the arithmetic out before you submit, because it tells you what to expect. A 1,273-residue protein contains 1,265 overlapping 9-mers, since 1273 minus 9 plus 1 is 1265. Run that against a panel of six alleles and you get 7,590 rows. Widen to lengths 8, 9, 10 and 11 and you have 5,058 peptides per allele, which is 30,348 rows for the same six alleles. Nobody reads 30,000 rows, which is the entire reason the filtering step below exists.

The same arithmetic gives you a useful sanity check. Percentile rank is calibrated against random natural peptides, so a 0.5% threshold should select roughly 0.5% of the peptides you submit for each allele. For 1,265 nine-mers that is around six strong binders per allele. If your table shows hundreds of strong binders for a single allele, something is wrong with your filter or your columns, not with the protein.

How do you turn thousands of rows into a shortlist?

Filter, then collapse by promiscuity. The goal is a short list of peptides that each bind several alleles in your panel, because those give you population coverage from a small construct.

1. Keep only strong binders first. Filter to BindLevel SB, or to Rnk_EL below 0.5 for class I. If that leaves too few peptides to work with, widen to the weak binder threshold and say in your methods that you did.
2. Count alleles per peptide. Group the surviving rows by peptide sequence and count how many distinct alleles each one appears under. This is the promiscuity count, and it is the single most useful number in your analysis.
3. Rank by promiscuity, then by best rank. A peptide binding five alleles at a rank of 0.4 is a better construct component than one binding a single allele at 0.01. You are designing for a population, not an individual.
4. Remove overlapping duplicates. Use the Pos column. Two 9-mers offset by one residue are effectively the same region of the antigen, so keep the better-ranking one and note the overlap rather than counting both as independent epitopes.
5. Stop at a workable number. Five to ten class I peptides and three to five class II peptides is a realistic shortlist for a student construct. Longer lists do not make the analysis stronger; they make the downstream filtering longer.

A spreadsheet handles all five steps for a single protein. If you find yourself repeating this for many antigens, that is the point at which learning to do the grouping in Python or R pays for itself, and it is one of the core skills on our computational biology skills roadmap.

What goes wrong, and how do you fix it?

These are the failures students hit in the first week, with what each one actually means.

What comes after the shortlist?

The shortlist is an input, not a result. In a reverse vaccinology workflow it feeds three further filters before anything is assembled into a construct: antigenicity scoring, allergenicity screening, and toxicity screening. Tools such as VaxiJen, AllerTOP and ToxinPred are the conventional choices at this stage, and each one removes candidates for a different reason, so run all three rather than treating any single score as decisive.

After that, the surviving peptides are joined with linkers and an adjuvant into a multi-epitope construct, and the construct itself moves into structural work: docking against an innate immune receptor such as TLR4, then molecular dynamics to check that the complex holds together. Those two steps are ordinary structural bioinformatics rather than immunoinformatics, and they are covered in depth in the docking and simulation material rather than here.

If you have not done the antibody side of the workflow yet, it is worth running first because it is more forgiving: our walkthrough on how to predict B-cell epitopes with BepiPred and ABCpred uses the same antigen and the same file-hygiene discipline. The full sequence of stages, and where each tool fits, is mapped on our learn immunoinformatics pillar.

Frequently asked questions

Is NetMHCpan better than the IEDB tool?

They are largely the same thing. The IEDB documentation states that its recommended class I method currently uses NetMHCpan 4.1 EL for epitope prediction and NetMHCpan 4.1 BA for binding prediction across all alleles. Use the DTU server for the full raw output columns, and the IEDB when you want its surrounding processing and immunogenicity tools in one place.

Should I filter on percentile rank or IC50 affinity?

Percentile rank. The NetMHCpan-4.1 documentation advises selecting candidate binders on %Rank rather than Score, because rank corrects for the tendency of some alleles to produce systematically higher or lower predicted affinities. Report the nanomolar IC50 alongside your shortlist as supporting information, not as the filter.

How many HLA alleles should a student project use?

Roughly six to twelve, chosen for a stated reason and recorded in your methods. Justify them by population frequency using the Allele Frequency Net Database, or by supertype representation with the scheme cited. NetMHCpan-4.1 caps submissions at 20 MHC types, and running near that cap makes almost everything look like a binder.

What peptide length should I predict for?

Start with 9-mers for MHC class I, which is the default digestion length on NetMHCpan-4.1, and keep the 15-mer default for class II on NetMHCIIpan-4.3. Class I supports 8 to 14 residues, so widening to 10-mers on a second pass is reasonable once your 9-mer analysis is complete.

Does a strong binder mean I have found a real epitope?

No. These tools predict MHC presentation, not T-cell recognition. A strong binder is a candidate for experimental validation, and any write-up should describe it that way. Cross-checking your shortlist against experimentally confirmed epitopes already recorded in the IEDB is the standard way to add confidence before you commit to a construct.

Where to go from here

T-cell epitope prediction becomes straightforward once the three decisions are separated: which alleles, which length, which column to filter on. Get those right and a 30,000-row table collapses into a shortlist you can defend. Get them wrong and no amount of downstream analysis will rescue the result. Run the spike example end to end, keep the raw output, and write your allele justification down as you go.

This guide was written by the StemSkills Lab team, which brings more than 10 years of work in sequence and structural bioinformatics, drug discovery and design, and multiscale molecular modeling.

Sources

• Reynisson B, Alvarez B, Paul S, Peters B, Nielsen M. NetMHCpan-4.1 and NetMHCIIpan-4.0: improved predictions of MHC antigen presentation by concurrent motif deconvolution and integration of MS MHC eluted ligand data. Nucleic Acids Research, 2020.
• NetMHCpan-4.1 service page and documentation, DTU Health Tech: peptide lengths, allele coverage, submission limits, output format and rank thresholds.
• NetMHCIIpan-4.3 service page and documentation, DTU Health Tech: class II lengths, isotype coverage, submission limits and rank thresholds.
• Immune Epitope Database and Analysis Resource: recommended prediction method, percentile rank definition and affinity interpretation.
• Allele Frequency Net Database: HLA allele frequencies by population, for panel selection.
• UniProt P0DTC2: SARS-CoV-2 spike glycoprotein, 1,273 residues, used as the worked example.