Storage & Card Doctor
betaCheck a memory card or drive: what is on it, how much room is left, what it really writes and reads, where it slows down when nearly full, and which recordings were cut short — with the fixes — and whether a computer formatted it, what it deleted but left behind, and how to repair and refresh it
How it works
Open the card — its root folder — in Chrome or Edge, pick the camera, and the doctor reads what is on it: files, folders and bytes by kind, the camera recognised from its file names, folders near the 999-file limit cameras impose, empty files, preview proxies left without their recording, and the clutter computers write onto exFAT cards (macOS ._ resource forks, .DS_Store, Spotlight and fseventsd folders, Windows Thumbs.db and System Volume Information). Used space comes from the files and free space from the card's size; the rule the verdicts apply is to keep a tenth of the card free. Every recording's tail is read for the index a camera writes when it closes a file, so the ones cut short when the camera stopped are listed. The speed test writes 1 to 32 GB of test files in 64 MB pieces and times each: the burst over the first quarter gigabyte, the sustained rate, the slowest second, and the point where the speed falls off — that is the card's write cache running out, and the rate after it is what the card really sustains. The files are read back and every byte checked against the pattern written, which measures the read speed and catches a card that corrupts data; then they are deleted. The verdict compares the slowest second with the speed class and with the camera's bitrate: a camera needs its bitrate in bytes with headroom, so 132 Mbps wants about 25 MB/s sustained, not the 30 MB/s a V30 label promises only when the card is empty. The fill test is for the card that works when empty and fails when nearly full: it writes the card full — to a margin you choose, or until the card refuses — charting the write speed against the space left, so the point where the speed falls under what the camera needs is visible; it finds the true free space, and reads samples back, which a counterfeit card fails past its real size. Large cards write quickly into a pseudo-SLC cache and move the data to the slow native flash later, and the cache and the controller's garbage collection both live on free blocks: with a few percent left there are none to spare, the writes go straight to native flash while the controller cleans, and the sustained rate falls — the camera's buffer overflows and it stops with a slow-card warning. Deleting single files on a computer fragments the free space and makes it worse. Each finding says what was found, why it matters and the fix: offload and format in the camera and keep the margin; a card larger than the camera's maker supports; a card whose sustained speed misses the class or the bitrate; a fake capacity; clutter, which a Clean button deletes after confirmation; a crowded folder; truncated recordings, which DJI cameras offer to repair at the next power-on. The report can be copied. Everything runs in the browser against the folder you picked; test files are removed when a test ends or is cancelled. The folders tell the card's history: recordings in a folder the camera never looks in (a DCIM renamed or copied on a computer), what a Mac or PC deleted but parked in the card's hidden Trash, the fragments a file-system repair left in LOST+FOUND or FOUND.000, a name only a computer gives. Paste the output of diskutil info (macOS) or fsutil fsinfo (Windows) and it reads the file system, the cluster size — 128 KB is what a camera's format makes past 32 GB, anything else means a computer or the factory formatted the card — the exact used and free space, so room used by nothing visible (clusters lost after a pull mid-write) shows up, and TRIM for an SSD. The fixes a browser can do run here: empty the card's Trash, delete repair fragments or moved folders after you have copied them off, clean computer files. A repair guide lists the rest in order: copy everything off, format in the camera (the menu path for yours), the SD Memory Card Formatter when a computer must do it, First Aid or chkdsk for a damaged file system, TRIM for SSDs — and why a card or SSD is never defragmented: the fragmentation that slows flash is inside the controller and only an erase clears it.
Questions
Why does my camera stop recording and say the card is slow only when the card is nearly full?
A big card writes fast into a pseudo-SLC cache and moves the data to its slow native flash in the background; the cache and the controller's clean-up both use free blocks. With a few percent free there are no spare blocks: writes go straight to native flash while the controller cleans up at the same time, and the sustained rate can fall under what the camera needs — the camera's buffer overflows and it stops. Deleting single files on a computer fragments the free space and makes it worse. The fix is to offload, format the card in the camera, and stop recording while a tenth of the card is still free; the fill test shows exactly where your card falls under your bitrate.
How do I test a card's real write speed?
Run the speed test with 8 GB or more. The first quarter gigabyte is the burst (the operating system's cache and the card's); the sustained figure and the slowest second are what a camera lives on. A cliff in the chart is the card's cache running out. The verdict compares the slowest second with the V30/V60/V90 classes and with your camera's bitrate with headroom.
Can it tell a fake card?
Yes: the fill test writes a known pattern into files until the card is full and reads samples back. A counterfeit card reports a capacity it does not have, and files written past its real flash come back wrong or vanish. A card whose flash is failing shows the same.
What does Clean delete?
Only the files computers write onto exFAT cards and that cameras do not expect: ._ resource forks, .DS_Store, .Spotlight-V100, .fseventsd, .Trashes, .TemporaryItems, Thumbs.db, desktop.ini, System Volume Information and $RECYCLE.BIN. You confirm the list first; recordings are never touched. Eject the card properly afterwards so the computer does not write them back.
Why format in the camera rather than on the computer?
The camera lays out exFAT the way its firmware expects — cluster size, alignment, folder structure — and a fresh format leaves the free space as one sequential run, so the camera's writes stay sequential. Deleting files on a computer leaves holes; a computer format may pick a layout the camera handles slowly.
How long does the fill test take, and is it safe?
As long as writing the free space takes: at 60 MB/s a terabyte is about five hours. The test writes only into its own BENCH_CARD_DOCTOR folder and deletes it when done or cancelled; your recordings are not touched. Keep the card plugged in and the window open — the page keeps the display awake and warns before you leave.
Does it read the card's health registers (SMART)?
No browser can: SD cards expose no SMART to a web page, and only a few industrial cards expose health at all. The doctor measures what matters in practice — what the card writes and reads at the end of its capacity, whether data comes back as written, and what the camera left behind — and judges that against the camera's needs.
How can it tell whether the card was formatted in the camera or on a computer?
From the cluster size in the volume details you paste: a camera's format (and the SD specification) gives a card above 32 GB 128 KB clusters, Windows gives a 1–2 TB card 512 KB, factory formats vary. A name on the volume is another trace — cameras do not let you name a card — and so are folders like DCIM-0 the camera never made. It matters because an operating system lays the file system out without regard to the flash underneath; the SD Association measured such cards at about 60% slower random writes than its aligned layout, and the camera's format also erases the flash, which is what resets a card that has slowed.
I deleted recordings from the card but it is still full. Why?
On a Mac, deleting from a card moves the files into a hidden .Trashes folder on the card itself; the room comes back only when the Trash is emptied with the card connected. Windows does the same in $RECYCLE.BIN when the bin is enabled for removable drives. The doctor shows what is parked there and empties it. Room used by nothing you can see is a different thing: clusters a pull mid-write left marked used, which only a file-system repair or a format in the camera reclaims.
Should I defragment the card or SSD?
No. Flash has no head to move, so fragments cost nothing to read, and a defragmenter's rewrites only use up write cycles. The fragmentation that slows a card lives inside its controller — blocks half full of stale data — and only an erase clears it: the camera's format or the SD formatter's overwrite format. Deleting files does not help because card readers pass no TRIM. An SSD tidies itself when the operating system sends TRIM, which exFAT never gets on macOS or Windows; APFS or NTFS do, and a full erase restores a drive that must stay exFAT.
Is anything uploaded?
No. Reading the files, writing and verifying the test files and the deletions all happen in your browser through the File System Access API; the card never leaves your computer.