Why a used microSD card tests slower than a fresh one, and what a format actually does

What does a used SD card look like on a bench?

It looks healthy. That is the whole problem. Every tool an ordinary owner can reach for, the file manager, a disk check, even reading every byte of the card back, reports nothing, because the thing that slowed the card down is not damage. It is a bookkeeping state inside the card’s controller, and only a write test can see it.

The clearest case I have is the Samsung PRO Plus 512GB, a card I reviewed in August with three units on hand. Unit A was sealed. It committed writes at 142.15 MB/s and held 141.56 through its worst ten seconds of continuous writing, which is V90 territory on a card printed V30. Unit B was a card I already owned. It had spent July and August 2025 in my VIOFO A229 Plus recording front and rear 2K, 318 clips and 20.7 hours of footage, filled the card once, and then I quick-formatted it. Windows called it empty and healthy. It wrote at 13.22 MB/s. Its worst ten seconds were 13.00, which holds V10 against the V30 printed on its face, and it did that on a settled run: the card was not recovering from anything, it was simply that slow.

Its reads were untouched: 157 MB/s sequential against Unit A’s 169, and the whole card read back at 169 on the verify pass. Every one of its 512.6 GB wrote and verified with zero errors. Twenty hours of recording and a single fill is roughly one program-erase cycle for a card rated for hundreds, so wear is not an explanation and I will not offer it. Something else was wrong with the card, and it turned out to be something I could undo.

The second case I did not go looking for. I bought a Gigastone High Endurance Pro 128GB sealed, and on its first run it held 59.56 MB/s through its worst ten seconds, then wrote and verified all 125 GB of itself in the capacity test and deleted the files. The next morning I ran it on my second reader to confirm the number, as I do for every card, and got 32.30. I assumed the reader. So I put it back in the first reader, the same slot the 59.56 had come from ten hours earlier, and got 31.04. The only thing that had happened to the card in between was that I had written every byte of it once.

Why does a card slow down after it has been written full?

Because its controller does not know the data is gone. A memory card’s controller keeps a map of which physical blocks hold something. When you delete a file, or quick-format the card, your computer rewrites a few kilobytes of filesystem bookkeeping and the controller is never told that the file’s blocks are free. On a computer’s SSD the operating system sends a TRIM command that says exactly that. Over a USB card reader nothing equivalent reaches the card: the reader talks mass storage to the computer, and the SD command that would carry the message never gets issued. So from the controller’s side, a card that has been written end to end and then emptied is still full. Every new write has to go into a block the controller believes holds something, and the controller has to make room first.

That is the state both cards were in, and I can say so with unusual confidence on the Gigastone because I watched it enter that state. Its capacity test writes the whole card in order, sampling the write speed every second. The floor held at 58.5 to 59.3 MB/s through its worst ten seconds for the first 80 GB. Past that it gave way: 55.4 at 82 GB written, 49.8 at 91, 47.1 at 99, then 45.5 and 45.4 over the last 17 GB. The first one-second sample under 35 MB/s landed at exactly 100.0 GB written, and the lowest of the whole fill, 23.07, at 122.7 GB. The last 25 GB carried twelve short episodes of one to five seconds each, and none was a full stop: the card never blocked a single write for longer than 93 milliseconds. It slowed to about a third of its speed for a few seconds at a time while it made room. Runs 2 and 3, on a card that now believed it was full, showed the same episodes from their first minute, seven of them on one reader and thirty on the other.

What settles it is the erase. On 18 September I put the card in a Raspberry Pi. The Pi’s own slot is a native SD host rather than a USB reader, so Linux’s blkdiscard there issues the real SD erase command that a reader cannot. It discarded all 125,069,950,976 bytes of the card in 26.5 seconds, far too fast to have erased any flash; the controller simply marked everything free, and the card read back as all ones at three points I checked before and after. Then a quick format with the SD Association’s own formatter, then run 4 on the same reader as runs 1 and 3: 54.53 through its worst ten seconds, not one sample under 40 MB/s, the nine-second write cycle locked in again. The 204 GB of writing the card had absorbed, 1.63 times its own capacity, had apparently been forgotten. Runs 2 and 3 had both run on a freshly emptied filesystem without recovering, so it was the erase that did it and not the format.

I have not opened this controller and I am not going to pretend to know its firmware. What I can say is that a bookkeeping explanation is the only one consistent with all four runs: the drop appeared only after the card had been written end to end, it did not depend on the reader, it survived deleting the files and a fresh filesystem, and it disappeared the moment the controller was told the data was gone. Wear would not do any of that.

The Samsung told the same story with a different ending. Its own registers report no discard support at all, so a quick format could never have reached its map either, and it did not: 13.00 after one. But the fix on that card was not an erase. It was a clean write of every block, which its own capacity test happens to be. The fill started at 15 MB/s, crawled through the first third of the card, climbed through the middle and stepped hard past 100 in the last fifth; the card was writing at 114 by the end. On the next run, with the card fully mapped again because the test had deleted its files, it held 113.98 through its worst ten seconds and wrote 123 flat across all 512 GB, the flattest fill in my corpus. One whole-card sequential write is what put the Gigastone into its slow state and what got the Samsung out of its own. Two controllers, two answers to the same operation. I do not know why they differ, and the honest version of this article says so rather than inventing a reason.

One more Samsung measurement matters for everything that follows. A third unit, C, arrived 40 percent full of clean, contiguous footage that had never been deleted or formatted, and it performed like the sealed one to within 1.4 percent. Filling it the rest of the way cost about 2.5 percent at the very end. One fill-and-delete cycle afterwards cost about 2 percent. Fullness is not the fault. Being full of data the controller has to shuffle before it can accept more is. Its review said that was a story for its own piece; this is the piece.

Is every used card slower? What 17 whole-card fills say

No. This is the part I want to be careful with, because it would be easy to read the two cases above as a rule and start telling people to erase every card they own. The bench says something narrower.

Every card that passes my capacity test has been written end to end once, on the same reader, with its speed sampled every second. That is a used-state measurement of every card in the corpus, for free: compare the worst ten seconds of the last quarter of the fill, when the controller is running out of never-written blocks, against the worst ten seconds of the first half, leaving out the opening 150 seconds that every fill spends settling. A card whose floor survives being filled holds near 100 percent. A card whose controller starts making room in the foreground falls below it.

Two cards fell. The Botslab 128GB, a card that came bundled with a dash cam, went from 51.5 to 42.0 with a lowest second of 28.3. The Gigastone went from 58.6 to 45.4, with a lowest second of 23.1. Both are on the same controller platform, the one that also ships under Newegg’s TeamGroup brand and inside the FitcamX bundle, and both write in the nine-second cache cycle that platform produces. That platform, five labels on one set of registers, is laid out in the identity explainer. The other two cards on that platform fold to a far lower speed the moment their cache fills, 5 and 8 MB/s at the bottom of the cycle, and held those floors through their fills; there was nothing left for a full map to take. Every other 128 GB card on the bench, three SanDisk High Endurance units, the MAX Endurance, two SanDisk Ultras, the Kioxia, both Lexars, the Amazon Basics, the Vantrue, the VIOFO, the PNY and the Samsung EVO Plus, held its floor within 3 percent or ended faster than it started.

The two genuinely old cards in the corpus are in that second group. The Samsung EVO Plus 128GB, which its own identity register dates to June 2019 and which had been in use since, wrote and verified all 128 GB with no slow region anywhere, and its fill ended 13 percent faster than it began. The SanDisk Ultra 128GB from September 2018 that I have used since then held 57.4 through its first half and 57.8 through its last quarter, and out-wrote the brand-new 2026 version of the same card by more than two to one. Age alone did nothing to either of them.

Two honest limits on that scan. It measures one fill of a card that was, in most cases, fresh, so it cannot see the state the Samsung PRO Plus arrived in, which took a dash cam and a quick format to produce; only one card on this bench has ever arrived like that, and I have no second unit with the same history. And the used SanDisk High Endurance 512GB I reviewed in September, a card with real dash cam service history, is not on this list because it is a different failure altogether. It was not slower than three fresh 128 GB units of the same line on any throughput measure. Its problem was a dead stop of 3.6 seconds in the middle of a write, reproduced on a second reader at 3.3 seconds, which no other card among 42 on this bench has ever produced. Nothing in this article explains that stall and I am not claiming a format or an erase would fix it.

And one card I cannot place. The Amazon Basics 128GB arrived sold as New with an Amazon returns-processing label on a box that has no seal, so I do not know whether anyone wrote to it before I did. It benched near the top of the corpus and its fill ended faster than it started. Prior use unknown is the phrase on its review, and it is the right one.

What does formatting an SD card actually do?

“Format the card” is the advice on every forum, and it hides four different operations that do four different things to the controller’s map. Here is what each one writes, what the card learns from it, and what happened when I did it.

The distinction that matters is between an operation that writes the card and one that discards it. Every kind of format your computer offers writes. A quick format writes a few megabytes and leaves the map exactly as it was; the Samsung had one before it wrote at 13, and the Gigastone had a clean filesystem for runs 2 and 3 and stayed at 31. A full format, an Overwrite format in the SD Association’s tool, or a zero-fill writes every block, which is the same thing my capacity test does, and I have now watched that operation repair one card and slow another. Only an SD erase discards, and no USB card reader I own can send one. A Raspberry Pi’s built-in slot can.

Whether your camera’s own format command erases the card or merely writes a filesystem, I cannot tell you, because I have not measured one. Some devices issue an erase when they format and some do not, and the only way to know for a particular camera is to measure the card before and after its format. That test is on my list, and until I have run it I am not going to guess.

How do you reset a slow SD card?

Measure first, then do the least destructive thing that the measurements support. Two cards is not a large sample, and they answered the same operation in opposite ways, so I am giving you the order I would follow rather than a single command.

1. Rule out the reader. The same card can read 96 MB/s on one reader and 180 on another, and a slow USB port alone can halve a result. Run the card in a second reader, or in the same reader twice, before you blame the card. How much the reader changes the answer and which one to buy are their own articles.
2. Confirm the card is real and healthy before you try to speed it up. A whole-card write-and-verify, with H2testw, F3 or my own CardCheck, is the test. Every byte written and read back correctly means the card is fine and slow, which is a state problem. Errors, or a capacity that comes up short, mean it is a different article: a counterfeit or a failing card, and no format fixes either.
3. Write the whole card once, in order, and measure again. That is what the verify test in step 2 already did, so measure right after it. On the Samsung, one contiguous write of every block was the entire fix, and it held through a second full mapping. On the Gigastone the same write was the cause. If your card came back faster, you are done; if it came back slower, step 4 is the only operation I have measured that reverses it.
4. For a real erase, use a native SD host. A Raspberry Pi with the card in its own slot, seated directly and not through an adapter or extender, will do it: check that /sys/block/mmcblk0/queue/discard_max_bytes is above zero, make sure nothing on the card is mounted, then sudo blkdiscard -f /dev/mmcblk0. It destroys everything on the card, including the partition table, so copy off anything you want first. The Gigastone’s took 26.5 seconds.
5. Then a quick format, and stop. A quick format puts a filesystem back and touches almost nothing. A full format after the erase would write every block and undo what you just did. The SD Association’s formatter reproduced the Gigastone’s factory layout exactly; Windows’ own quick format gives the same cluster size with a slightly different partition offset, which is fine.

Should you format a dash cam card, and how often?

A dash cam writes in a loop: it fills the card, then deletes the oldest clip to make room for the next, and does that for as long as it is powered. So a card in a dash cam is in the fully written state permanently, from about its first day of service, and nothing the camera does will ever tell the controller otherwise unless the camera’s own format issues an erase, which I have not measured on any camera. That is why the number that describes a dash cam card is its used-state number, and why the Gigastone is scored in its used state on its review, with the fresh figure reported beside it.

Format for the filesystem, not for speed. A quick format or an in-camera format repairs a directory the camera has tangled, clears out locked event clips you no longer need, and gives the recorder a clean allocation table to write into. All of that is worth doing when the camera asks for it, when it has thrown a card error, or after you have pulled clips off the card on a computer. None of it makes the card faster, because none of it reaches the map. And on most of the platforms I have tested, the difference between fresh and used never showed at all.

The question underneath is whether the used state matters to the camera, and for the cards I have measured it did not. The Gigastone in its used state still held V30 on both readers, with its worst single second at 23 MB/s against the roughly 6.6 MB/s a dual-channel 2K camera like the A229 Plus actually writes. The card slowed for a few seconds at a time; it never stopped. A camera with a small buffer and a continuous stream cares about a dead stop far more than it cares about a dip, which is the caution the used SanDisk High Endurance 512GB carries: it passed every speed class on every run, and the 3.6-second stall it produced on two readers is the kind of thing that throws a card slow warning. That is a different failure from anything in this article, and I have said so on its review.

A dash cam never erases its card. The used state is the state the product lives in, and it is the one I now score.

What this changed about how I test

The card’s state at the start of a run is now a recorded variable. Since version 1.22 of the review protocol, dated 18 September 2026, every run in a card’s case file says whether the card was sealed, had been through a capacity fill, or had been erased from a native host since, and when a card’s two floors differ the review reports both and says which one the score used. It also carries a rule I wish I had had a week earlier: before blaming a disagreement between two readers on the reader, slice the first run’s fill into 150-second windows and look at the last third. The Gigastone’s answer was sitting in run 1 the whole time, on the first reader, before the second reader was ever involved. The rest of the method, including why every write is committed before it is counted, is on the scoring page, and every card’s standing is on the CKBench hub.

What I have not done yet is the experiment that closes the loop for camera owners: a card measured before and after a specific camera’s own format, to see whether that camera erases. Until that runs, the honest advice stays what it is above. A quick format is for the filesystem. Speed comes back only through an erase from a native host or, on some controllers, a clean write of the whole card, and the way to know which your card wants is to measure it.

A used card is a state, and a state can be reset

The used card in your drawer is probably fine. If it verifies clean, it is not worn out, whatever its write speed says today. What its write speed says is what its controller believes about the data on it, and that belief survives a delete, a quick format, and the kind of format your camera runs. On most cards it never matters; on some, it halves the floor. When it does, there are exactly two operations I have measured that undo it: a clean write of the whole card, which helped one card and hurt another, and an SD erase from a native host, which is the only one I have seen return a card to its out-of-box floor.

Measure before and after, whichever you try. That is the whole method on this site, and it is the only reason I can tell you the difference between a slow card and a slowed one.