Why two identical SD cards test differently

What "the same card" means to the card

A memory card knows exactly what it is, and it will tell any host that asks in the right way. Four small read-only registers carry the answer, and this whole article is about reading them.

The CID, the card identification register, holds a manufacturer ID, an OEM ID, a five-character product name, a firmware revision, a serial number and a manufacture date. It is the card's birth certificate, and it is the register the CKBench register page catalogs across every card I have read, thirty-four cards and ten distinct manufacturer IDs as of 19 September 2026. The CSD declares what the card is: its size in allocation units, which is where the byte count on the hub comes from. The SCR and the SD Status declare what the card can do: the specification version, the bus widths, the speed classes it claims and the erase behavior it supports.

When two cards are the same design, all four registers agree except the serial and the date. When they are not, the registers disagree, and the disagreement is visible before a single byte is written. Which means the question in the headline has an answer you can check rather than argue about. Here are four cases, all from cards physically on my bench, all with the registers read on a Raspberry Pi's native SD slot and the numbers taken from the run files.

Same model code, same barcode, different silicon

SanDisk High Endurance 128GB, model code SDSQQNR-128G-GN6IA, UPC 619659173104, three units. Two were bought new for the bench in 2026. One I already owned. At the point of sale they are indistinguishable: one SKU, one barcode, one retail listing. Here is what their registers say.

Units A and C are the same design: the same product name, SA128, the same revision, the same declared capacity to the byte, and CSD, SCR and SD Status identical. Unit B is something else. Its product name is SN128, its firmware revision is older, it declares exactly 134,217,728 fewer bytes, and all three of the other registers differ. It was also built in April 2025, before either of the other two, even though it is the SKU a buyer would have received for most of a year: the older build under the same barcode. The only thing on the cardboard that gives it away is a copyright line, Western Digital 2022 on unit B's box against Sandisk Corporation 2025 on unit A's, which is a corporate-era tell and not a specification.

Now the bench, same reader for all three, the ProGrade PGM0.5, worst ten seconds being committed sequential write over five minutes, and the reader named because the reader changes the answer.

Read the first two rows and then the third. A and C agree to a hundredth of a megabyte per second on read and to the exact figure on write and worst ten seconds, three weeks apart, which is what "the same card" looks like when it really is the same card. Unit B reads 1.81 times faster, because its controller speaks the DDR200-class extension the other two do not, and it proved that on the whole-card verify at 179.98 MB/s, not just on a one-gigabyte file. It writes faster too, and it is 30 percent worse at random small writes, 716 IOPS against 1,030. Faster in one direction, slower in another, and the same product to every system that sells it.

The consequences are not academic. The review of this card describes unit A, and it says so now: it describes one of two builds a buyer might receive. The 88.0 MB/s floor that review carries is unit A's, and it is the corpus's reference anchor because unit A is the unit that reproduced itself on a second card; unit B's 100.77 is a different card's number and is filed under a different letter.

Two cards you cannot tell apart in a shop differ by 81 percent on read. Their registers told the difference before the first byte was written.

Same name, eight years apart, opposite directions

SanDisk Ultra 128GB. The face of the card prints the brand, the line, the capacity and the class marks, and no speed and no model code. SanDisk has sold that face at several different rated speeds over the years, so the name alone does not tell you what you own. My two units are a 2018 card and a 2026 card, and the registers put a date and a product name on each.

The model code changed with the generation: the 2026 box prints SDSQUJQ-128G-GZ6MA and a 195 MB/s read rating, where the 2018 card's generation was rated 100 MB/s and its face prints nothing. So this pair is not one SKU, it is one product name across two SKUs, which is the more common way the same card turns out to be a different card. The review tests both, on two readers, and the split runs in opposite directions.

The 2026 card reads 2.1 times faster on the same second reader, and beats its own 195 rating there at 203.47, which took a second host to prove because the primary reader's slot tops out near 181. The same 2026 card writes at 41 percent of the 2018 card's rate, 25 against 61 MB/s, on both readers. Newer, faster, slower. If a review of "the SanDisk Ultra 128GB" quoted one write number without a build date, it would be wrong for one of these two cards by a factor of 2.4.

Twins in one batch, and a generation apart

Samsung PRO Plus 512GB, three units. Unit A was sealed until it went on the bench, model MB-MD512SA rated 180 and 130 MB/s. Unit C was bought as a check on unit A. Unit B had been in one of my dash cams since 2023 and belongs to the previous generation, MB-MD512KA, which Samsung rated at 160.

A and C are what a same-batch pair looks like: the same product name, the same month of manufacture, serial numbers that share their first byte, and three registers identical to the last bit. On the bench every figure lands within 1.4 percent, and the review says exactly that: two cards from one batch cannot prove a production run is consistent, but they rule out the most obvious way a single-unit review goes wrong. Unit B is the generation before. Its product name is FF8S5, it was built in September 2022, it shares the CSD and SCR with the newer pair and differs only in its SD Status, and once its state had been reset it wrote at 123.51 MB/s against the newer pair's 142.15, which is 87 percent, on the same reader.

That third row is the trap this article is not about. Unit B arrived writing at a tenth of its rated speed with nothing wrong with it, and one whole-card write brought it back to the fourth row. That is a card's state, not its identity, and it has its own article. What identity accounts for is the gap between the fourth row and the first two: an older generation writing 13 percent slower than the current one under the same name, which the registers announced before the run.

One clause on something I have not written up: the PRO Plus pair's CSD, SCR and SD Status are also identical to my Samsung PRO Ultimate 512GB's, a different product line on the same platform. Same registers, different label, which is the mirror image of everything above and the subject of the next case.

Different names, one platform

If one name can hide two chips, one chip can wear five names. The PNY Premier-X 128GB reports manufacturer ID 0x74 in its CID, a value nothing else on my bench reports. Its CSD, SCR and SD Status are byte-identical to the Gigastone High Endurance Pro 128GB, which reports 0xFE, and its SD Status is identical to three more 0xFE cards: the Newegg TeamGroup, the Botslab that came bundled with a dash cam, and the FitcamX that came bundled with another. The Gigastone's CID even repeats the TeamGroup's field for field, except the serial and the date.

Two things follow, and one thing does not. First, the manufacturer ID is the assembler's field, not the chip maker's: the same controller platform shows up behind two different IDs, so I do not name a maker for any of these, and neither should anyone reading a lookup table. Second, the capacity is per lot, not per platform: five cards, four different declared byte counts, the PNY and the Gigastone alone matching to the byte. What does not follow is that identical registers mean identical behavior. Those five cards' worst ten seconds run 35.5, 43.8, 53.9, 59.56 fresh and 47.08, and the way each one folds when its cache fills is different again. The registers say what platform a card is. They do not say how it was configured, which flash it got, or how it was graded.

The vendor says so, in writing

None of this is a secret and none of it is misconduct. A consumer card is a product line, and the line is maintained for years while the controllers and the flash under it change with whatever is available and cheapest to build. SanDisk put it in a white paper for its industrial customers in January 2026, explaining why they should not buy consumer cards for cameras that have to keep working:

That is the thesis of this article, in the vendor's words. The same document is the one that explains why consumer cards carry an hours rating instead of a bytes rating. Read together, the two sentences say that the model code on a consumer card is a contract about the label and the marks, both of which every unit above honored, and not about what is inside.

What this does to a review, including mine

A review measures a unit. That sentence used to be a caveat and it is now the method. Every figure on this site is attributed to a unit, a reader and a state, because each of the three can move the number by more than the difference between two competing cards: a unit by 81 percent on read, a reader by a full video speed class, a state by a factor of ten. Write speeds are measured with every byte committed to the card, the way a camera writes, so they read lower than burst benchmarks; the scoring page explains why.

Three things changed on this bench because of the cards above. Every card's CID is dumped on a native SD slot before it is benched, so a second unit is compared to the first by register before it is compared by number. Units keep their letters for good: the High Endurance review's anchor is unit A's, the corpus's reference band is built on unit A because unit C reproduced it, and unit B's figures are unit B's. And every read figure names the reader it was measured on, with a second host run before any read number is reported as the card's limit rather than the host's.

It also changes how to read anyone else's number. A speed figure with no build date, no reader and no unit is a description of one card on one afternoon, and it may be a perfectly accurate description of a card you cannot buy any more.

The same card also tests differently for two reasons that are not the card

The host. The reader and the port it hangs off set a ceiling the card cannot exceed, and on this bench that ceiling has been measured twice over: the primary reader's microSD slot tops out near 181 MB/s on read, and since protocol v1.21 it has a write ceiling too, near 157, found when the Amazon Basics 128GB held 155.92 MB/s through its worst ten seconds there and 188.11 on the second reader, same card, same day. That whole story, the four host tiers and the USB port that costs more than any of them, belongs to the reader tiers post and its buying companion, and I am not retelling it here.

The state. A card that has been written end to end and never told which blocks are dead can hold a lower floor than the same card fresh, with nothing worn and every byte intact: the Gigastone above floored at 59.56 sealed and 31.04 used, and the PRO Plus unit B wrote at 13.22 as it came out of a dash cam. That is a card's condition, it is reversible, and the used-card explainer owns it, with the erase experiment that settled the mechanism.

Identity is the third variable, and it is the one nobody can reset. A different build is a different card for as long as you own it.

How to know which one you have

1. Read the model code before the brand. It is on the box and often on the card's back, and it changes with the generation more often than the face does: SDSQUAR became SDSQUJQ on the Ultra, MB-MD512KA became MB-MD512SA on the PRO Plus. It does not catch a silicon change inside one model code, which is case one.
2. Read the CID on a native SD slot. A USB card reader hides the registers behind a bridge chip; a Raspberry Pi, or any Linux machine with a built-in SD slot, exposes them in sysfs. The register page has the walkthrough; the files are these:
   /sys/block/mmcblk0/device/cid   the whole register
   /sys/block/mmcblk0/device/manfid   /sys/block/mmcblk0/device/oemid   /sys/block/mmcblk0/device/name   /sys/block/mmcblk0/device/date
3. Decode it. Paste the CID into the CID decoder and it returns all seven fields, looks the manufacturer ID up against the register, and tells you whether the identity matches a card already on this bench.
4. Compare the product name and the date, not the serial. Two units of one build share a product name and a firmware revision; the serial and the month differ on every card and prove nothing. SA128 against SN128 was the whole difference in case one.
5. Then read any review's number as one unit's number. If it names a build date, a reader and a unit, you can tell whether it describes your card. If it does not, it describes somebody's card.

The card knows what it is

The box tells you what the card is called and what it is rated to do, and on every unit above the marks were honest. What the box cannot tell you is which build you got, and that turned out to be worth 81 percent on read, 2.4 times on write, and a different answer on small files, across cards sold as the same thing. The card itself can tell you, in a register that costs nothing to read, and the difference between a review that names its unit and one that does not is the difference between a measurement and a rumour.

So read the model code, read the CID when it matters, and hold every number, mine included, to a unit, a reader and a state. That is the whole method, and it is why the three High Endurance cards in this article have three letters instead of one review.