Read and decode your SD card's CID register
Every SD card carries 128 bits of identity data it will recite on request: who built it, what it calls itself, when it was made. Paste those 32 characters below and this page pulls them apart, then checks the manufacturer ID against a register I built by reading the cards myself.
Paste a CID, get every field
Thirty-two hex characters. Spaces, colons and a leading 0x are all fine, they get stripped. Nothing you type leaves your browser: the decoding, the lookup and the match against my register all happen on this page, and there is no request to any server.
| Field | Value | What it is |
|---|
The serial number is the only field here unique to your individual card. It is shown because it is yours, and the copy button above leaves it out, because it is the one field worth removing before you send a register to anybody, me included.
If the manufacturer ID comes back with no name attached, that is worth reading correctly, and it is the single most misunderstood thing about this register. It does not mean the card is fake. It means nobody who publishes a list has catalogued that number yet. The register page explains why no list can ever be complete, using a card on my own bench that is unlisted and completely honest, and a counterfeit that reports a flawless SanDisk identity.
How to get the CID off your own card
This is the hard part, and it is hardware, not software. Below, every route is marked with whether I have actually run it. I have read twenty cards this way and I am only going to vouch for what I did myself.
Before anything else: a USB card reader will not work.
The card speaks SD on one side and the reader speaks USB mass storage on the other. The command that asks for the identity registers does not survive that translation. This is the single most common reason people try once and conclude their card is broken. You need a slot wired directly to the host, not a dongle.
Linux, and a Raspberry PiVerified here
This is the route every register on this site was captured with, on a Raspberry Pi 4 with the card in the native slot and no USB bridge anywhere in the path. The kernel exposes the registers as plain files, so there is no tool to install:
cat /sys/block/mmcblk0/device/cid
That prints the whole 32 character register, which is what this page's decoder wants. The individual fields are alongside it, already decoded by the kernel, which is a useful cross-check against the decoder above:
| Path | Returns |
|---|---|
| /sys/block/mmcblk0/device/cid | The whole register as hex |
| /sys/block/mmcblk0/device/manfid | Manufacturer ID |
| /sys/block/mmcblk0/device/oemid | OEM ID |
| /sys/block/mmcblk0/device/name | Product name |
| /sys/block/mmcblk0/device/date | Manufacture date |
| /sys/block/mmcblk0/device/serial | Serial number |
Two practical notes. If the machine also boots from an SD card, the one you want may be mmcblk1 rather than mmcblk0; lsblk will show you which is which by size. And reading these is completely harmless. Nothing is written to the card, and it does not even need to be mounted.
One quirk that will otherwise worry you, measured across every card I have read: the last byte comes back as 00. That is the CRC, and Linux does not deliver it, because the host controller consumes it while receiving the response. A CID read this way cannot be checksum-verified, and the decoder above says so rather than reporting a failure.
WindowsNo verified method
I do not have one, and I want to be straight about that rather than pad this section out.
The rest of CKBench runs on a Windows bench. The Raspberry Pi rig exists purely because that Windows bench cannot read a CID through any reader I own, and building a separate machine was easier than finding a way. Built-in laptop slots are not a reliable escape either: plenty of them are internally a USB bridge, which puts you back at the translation problem above.
There are third-party utilities that claim to do this. I have not run them, so I am not going to name them and imply an endorsement I have not earned. If you want a CID from a Windows machine today, the two routes I would actually trust are booting it from a Linux live USB and using the path above, or spending very little on a Raspberry Pi.
macOSUnverified
I do not own a Mac, so everything in this paragraph is secondhand and labeled accordingly. The hardware side is at least plausible: the built-in slot on many Mac models is wired to the internal bus rather than through USB, which is the condition that matters. The command usually suggested is system_profiler SPCardReaderDataType. I have not run it, I do not know whether it exposes the raw CID or only a friendly summary, and I am not going to write it up as though I had.
If you run that on a Mac with a card in the slot, I would genuinely like to see what it prints. That is one of the more useful things anybody could send me for this page.
AndroidUnverified
An Android phone with a microSD slot is a Linux machine with the card on a native host, so the same /sys/block/mmcblk*/device/cid path is reported to work, generally needing root to read. I have not tested it on any handset and cannot tell you how much it varies between manufacturers.
What each field actually is
The CID is 128 bits, laid out the same way on every SD card. Five of the seven fields are model level: every card off the same production line reports identical MID, OID, PNM and PRV, and near enough the same date. Only the serial is yours.
| Field | Size | What it holds |
|---|---|---|
| MID | 8 bits | Manufacturer ID, assigned by SD-3C LLC and not published anywhere official |
| OID | 16 bits | OEM or application ID, in practice two ASCII characters, though not always printable ones |
| PNM | 40 bits | Product name, five ASCII characters. Plenty of cards use fewer |
| PRV | 8 bits | Product revision, as x.y |
| PSN | 32 bits | Serial number, unique to the individual card |
| MDT | 12 bits | Manufacture date, month and year, counting from 2000 |
| CRC | 7 bits | Checksum. Usually missing from a CID read on Linux, see above |
What this decoder cannot tell you
Most people who go looking for a CID decoder are trying to work out whether a card is counterfeit. This tool will not answer that, and neither will any other one, so it is worth saying plainly here rather than burying it.
I own a counterfeit microSD card. It is sold as a 128GB SanDisk, it is physically a competent 32GB card, and its label is a lie. Paste its CID into the box above and you get a flawless SanDisk signature: manufacturer ID 0x03, OEM ID "SD", a coherent product name, a plausible revision and date. Every field checks out. The card is still a fraud.
Meanwhile several completely honest cards on my bench report manufacturer IDs that resolve to nothing at all on any list in existence, and every one of them delivered every byte it promised.
Verify the capacity, not the identity.
Fill the card, read it back, compare. A counterfeiter can write any string they like into a register, but they cannot conjure flash that is not physically there. That is the one test worth running on a suspect card, and it is described in full on the how we test and score page.
Send me a register I do not have
The register behind this decoder is not a copy of somebody else's list. It is twenty cards I have physically read, and it can only ever grow by somebody reading another one. Because there is no official registry, that is the only way any of this gets better.
The specimen worth sending is a card whose retail identity is known and whose manufacturer ID currently resolves to nothing, because that pairing is what turns an unknown number into a named supplier. Bundled cards, house brands, dash cam accessories and phone maker cards are where those live. A name brand card whose maker is already public adds a row and teaches nobody anything.
If the decoder tells you your manufacturer ID has no name, or that it is one of the unnamed signatures already in the register, here is what to do:
| Step | What to do |
|---|---|
| 1 | Decode the CID above |
| 2 | Press Copy without the serial, which formats the whole thing and leaves out the one field unique to your card |
| 3 | Add the brand, the exact model as printed, and where you bought it |
| 4 | Send it through the contact page, which arrives tagged as a CID submission |
What happens to it: a CID with the serial removed is model level data with nothing personal in it. If it names a manufacturer ID I do not have, it goes in the register with the source described the way I describe my own cards, and where I am unsure of the attribution the row says so. This page carries no affiliate links.
Frequently Asked Questions
Can the CID tell me if my SD card is fake?
No. The counterfeit card on my bench reports a perfect SanDisk identity, and two honest cards next to it report manufacturer IDs that appear on no list anywhere. Card controllers are programmable and whoever writes the firmware decides what the registers say. The only reliable test is writing the full capacity and reading it back.
Why does my CID end in 00, and is the checksum broken?
It is not broken. When you read a CID through Linux, the last byte holds the CRC and it comes back as zero, because the host controller consumes the checksum while receiving the card's response and never passes it up. Every one of the cards I have read shows this. The decoder on this page recognizes it and reports the checksum as absent rather than failed.
Why does my USB card reader not work for this?
Because it is a translator, not a wire. The card speaks the SD protocol and the reader speaks USB mass storage, and the command that requests the identity registers has no equivalent on the other side, so it never reaches the card. You need a slot connected directly to the host, which in practice means a Raspberry Pi, some built-in laptop slots, or a dedicated SD host adapter.
How do I read an SD card CID on Windows?
I have no method I can vouch for. The Windows bench the rest of my testing runs on cannot read a CID through any reader I own, which is the reason I built a Raspberry Pi rig for it. Third-party utilities exist and I have not tested them, so I will not recommend them. Booting the machine from a Linux live USB and reading the sysfs path is the route I would trust.
My manufacturer ID is not on the list. Is that bad?
No, and it is the most misread result there is. Manufacturer IDs are assigned by SD-3C LLC, which treats the assignments as confidential and publishes no list. Every list in existence, mine included, was assembled by reading cards whose brand was already known. An unrecognized ID means nobody has catalogued that number yet. It says nothing whatsoever about the card.
Is it safe to share my card's CID?
Remove the serial number first and it is model level data, identical on every card off that production line, with nothing personal in it. The serial is the one field unique to your individual card, which is why this page's copy button leaves it out and why the published register omits it on every row.
See what these registers turned up
Three unrelated brands selling one supplier's card, a Lexar reporting the wrong manufacturer number, and a counterfeit with a flawless identity. All of it read off cards on the bench.
Open the CID register