Direct comparison

TPM vs FPKM vs Raw Counts

RNA-seq units compared: what raw counts, FPKM/RPKM and TPM each normalize for, why FPKM isn't cross-sample comparable, and which fits DESeq2/edgeR.

Written and maintained by CASRAI Editorial Board

Last updated 3 September 2026

Ask CASRAI · included with Regulatory Radar

Ask about TPM vs FPKM vs Raw Counts

Ask CASRAI answers research-administration questions and cites the passages behind every claim — and says so when the corpus does not cover something, instead of guessing. It comes with a Regulatory Radar subscription at $29 a month, alongside the daily digest of regulatory changes and the dashboard of what changed.

150 questions a day, on this site, over the API, or inside your own tools through the CASRAI MCP server.

Subscribe — $29/month See what it covers →Already subscribed? Sign in

Everything CASRAI publishes — this page, the dictionary, the guides and the news — stays free to read, with no account and no card.

In summary

Raw counts, FPKM/RPKM, and TPM are the three expression units you'll encounter in RNA-seq output, and mixing them up in the wrong place is one of the most common analysis mistakes. Raw counts are unnormalized read/fragment tallies per gene or transcript — the correct input for count-based differential expression tools like DESeq2 and edgeR, which normalize internally. FPKM (or its single-end predecessor RPKM) normalizes for both gene length and sequencing depth, but has a well-documented flaw: because the depth correction is applied after length normalization, FPKM values don't sum to the same total across samples, so an identical FPKM number represents a different share of the transcriptome in different samples — making direct cross-sample comparison misleading. TPM normalizes for the same two factors but reverses the calculation order (length first, then depth), so TPM values sum to exactly one million in every sample and are directly comparable within and across samples. Use raw counts for DE testing; use TPM for comparing relative expression.

How do Raw Counts, FPKM / RPKM, TPM compare side by side?

The table below compares Raw Counts, FPKM / RPKM, TPM across 7 procurement-relevant dimensions, from what it normalizes for through introduced / formalized by.

Side-by-side comparison

Dimension	Raw Counts	FPKM / RPKM	TPM
What it normalizes for	Nothing. Both sequencing depth and gene/transcript length are left in the number as-is.	Sequencing depth (library size) and gene/transcript length.	The same two factors as FPKM — gene/transcript length and sequencing depth — but calculated in reverse order.
How it is calculated	Read/fragment counts assigned to a gene or transcript by an aligner (STAR, HISAT2) or pseudo-aligner/quantifier (Salmon, kallisto, RSEM). No further math.	Divide each gene’s counts by its length in kilobases (reads per kilobase, RPK), then divide by the sample’s total mapped reads/fragments in millions.	Divide each gene’s counts by its length in kilobases (RPK) first, then divide every gene’s RPK by the sum of ALL genes’ RPK values in that sample, scaled to per million.
Do values sum to the same total in every sample?	No — the sum is the sample’s total mapped read count, which varies with sequencing depth.	No. This is the well-documented problem: because depth-correction happens after length-normalization, the sum of FPKM across all genes differs sample to sample, so equal FPKM values in two samples do not represent equal proportions of those samples’ transcriptomes.	Yes. By construction, TPM values in a sample always sum to one million, so a TPM of 500 in sample A represents the same proportional share of the transcriptome as a TPM of 500 in sample B.
Reliable for cross-sample comparison of relative expression?	No — larger library, larger counts, with no depth correction at all.	No, despite looking normalized. This is the classic pitfall the FPKM-vs-TPM comparison exists to flag.	Yes — this is the use case TPM was designed to fix.
Correct input for DESeq2 / edgeR / limma-voom?	Yes, required. Each tool’s own documentation specifies raw or estimated (non-normalized) integer counts as input; they compute their own size factors (DESeq2’s median-of-ratios, edgeR/limma’s TMM) internally.	No. Feeding a pre-normalized value in breaks the count-based mean-variance model these tools fit.	No, for the same reason as FPKM — length- and depth-normalized values are not valid DE-test input.
Typical source / where you’ll see it	featureCounts, HTSeq, or a quantifier’s counts output — the DE-tool input matrix.	Legacy output from early tools such as Cufflinks; still common in older public datasets and some genome browsers.	Native output of modern quantifiers (Salmon, kallisto, RSEM); the unit used by GTEx and most current expression atlases.
Introduced / formalized by	Not a normalization method — a direct aligner/quantifier output.	RPKM: Mortazavi et al. 2008 (Nature Methods). FPKM: Trapnell et al. 2010 (Cufflinks, Nature Biotechnology) extended the measure to paired-end fragments.	Formalized by Li & Dewey 2011 (RSEM, BMC Bioinformatics); the cross-sample comparability problem with RPKM/FPKM was made explicit by Wagner, Kin & Lynch 2012 (Theory in Biosciences).

Common questions

Common questions about Raw Counts vs FPKM / RPKM vs TPM

Can I convert FPKM to TPM after the fact?

Yes. TPM_i = (FPKM_i ÷ sum of all FPKM values in that sample) × 10^6. Because the conversion only rescales by the sample’s own FPKM total, it fixes the cross-sample comparability problem retroactively — but it can’t recover accuracy lost if the original FPKM values used different effective-length or gene-model assumptions than a native TPM calculation would.

Why do DESeq2 and edgeR insist on raw counts instead of TPM or FPKM?

Both tools fit a count-based statistical model (negative binomial) where the variance at low counts is informative — a count of 8 and a count of 8,000 carry different levels of measurement uncertainty. Dividing by length or library size before the tool sees the data destroys that information and also means the internal size-factor/TMM normalization is being applied on top of an already-normalized number, which is not what the model assumes.

Are RPKM and FPKM the same thing?

Nearly. RPKM (reads per kilobase per million) came first, for single-end sequencing, where one read equals one sequenced fragment. FPKM (fragments per kilobase per million) was introduced for paired-end data, where two reads can represent one sequenced cDNA fragment — FPKM counts that pair once, avoiding double-counting. For single-end libraries the two values are numerically identical; the different name just signals which counting convention was used.

If TPM sums to the same total in every sample, is it fully normalized and safe for any comparison?

No. Summing to a constant only guarantees within-sample proportions are on a comparable scale — it does not correct for compositional bias, where a handful of very highly expressed genes make up a different share of the RNA pool between conditions, or for technical/batch effects. DESeq2 and edgeR address compositional bias with median-of-ratios or TMM normalization on raw counts; plain TPM does not perform that correction.

What should I use for a bar chart, heatmap, or box plot comparing expression across many samples?

TPM, often log-transformed as log2(TPM + 1), is the standard unit for that kind of descriptive or visualization use, precisely because of the cross-sample comparability FPKM lacks. For a statistical claim about differential expression, use the DE tool’s own normalized values (DESeq2’s variance-stabilizing transformation, or edgeR/limma’s logCPM) rather than raw TPM.

Does using a pseudo-aligner like Salmon or kallisto instead of STAR change which unit I should use?

Not fundamentally. The right unit depends on what the downstream step needs — raw counts for a DE tool’s internal model, TPM for comparison or visualization — not on which upstream tool produced the numbers. Alignment-based counting (STAR + featureCounts/HTSeq) natively outputs raw counts; quantifiers such as Salmon, kallisto, and RSEM output both estimated counts and TPM from the same run, which is a convenience, not a reason to pick a different unit than the analysis step calls for.

Going deeper