Paste your drive's SMART data. Get plain English.

How to get your SMART data

You need smartctl from smartmontools (brew install smartmontools). Then:

• smartctl -a disk0 — full attributes (swap disk0 for your drive; diskutil list shows them).
• On an Apple-Silicon internal SSD, also try system_profiler SPNVMeDataType — macOS exposes only a basic SMART status there (see below).

Paste the whole thing into the box above. It never leaves your browser.

Puzzled by a _underscore name in Activity Monitor instead? Use the system-account decoder.

What the key attributes mean

Percentage Used (NVMe)

The drive's own vendor-specific estimate of how much of its life has been used. It's a wear gauge, not a countdown — it can pass 100% and the drive keeps working.

Data Units Written → TBW

Lifetime host writes, approximately: one NVMe data unit = 1,000 × 512 bytes and the drive rounds the unit count UP, so TB written ≈ data-units × 512,000 ÷ 10¹². A value of 0 means the drive did not report it, not zero bytes. Compare it to your drive's rated TBW (on its spec sheet).

Available Spare + Threshold

The drive's normalized remaining spare capacity. A value BELOW the threshold is what the drive itself treats as low — a real signal to back up and plan a replacement. Exactly AT the threshold is the boundary, not the trigger.

Media & Data Integrity Errors

Occurrences where the controller hit a data-integrity error it could not repair. A non-zero count means such an event already happened; the published monitoring rule is that the count has increased between two checks, which one paste cannot show, so the decoder reports the number without raising an alarm on it.

Reallocated / Pending / Uncorrectable sectors (SATA)

Retired, unstable, or unreadable sectors. For pending and offline uncorrectable sectors under their standard names, smartmontools’ own smartd treats any non-zero count as something to report, and so does this decoder. For reallocated sectors the published rule is different — it watches for the raw count changing between two checks (any change, not only an increase), which a single paste cannot show — so the decoder shows the number and the drive’s own verdict columns without calling it a warning. Compare it against an earlier reading of the same drive.

Power-On Hours & Cycles

On NVMe, Power On Hours is defined as hours, so ~8,760 of them is a year of 24/7. On SATA/ATA the same idea lives in attribute 9, whose unit is not standardised — the drive database overrides it to minutes, seconds or half-minutes for some families — so the decoder shows that one as a bare counter and does not convert it. Power cycles are counted events either way.

Why system_profiler shows so little on Apple Silicon

system_profiler shows only a basic SMART Status: Verified — not Percentage Used or Data Units Written. That is a limit of that command, not of your drive: a current smartmontools can read the internal Apple-Silicon NVMe health log directly — smartctl -a /dev/disk0 returned the full log on an Apple-silicon Mac we tested with smartmontools 7.5 (see the SSD-endurance field guide for the measured dataset). Exposure still varies by Mac and macOS version, so if smartctl comes back empty, record that limitation rather than assuming a number. External USB enclosures are the opposite case — the bridge chipset in between can pass no SMART data through at all.

FAQ

Is my SMART data uploaded anywhere?

No. The decoder parses the text you paste entirely in your browser tab. There is no upload — you can confirm it in your browser's DevTools Network panel: pressing Decode makes no network request.

Can it tell me if my drive is about to fail?

No. SMART attributes alone cannot reliably predict an individual drive's failure or its date — in Google's field study a large share of failed drives had shown no prior SMART warning at all. This decoder reports the numbers, explains what's normal, and flags the signals a published source actually defines as such (pending and offline-uncorrectable sectors, available spare below the drive’s own threshold, and every failure the drive itself declares). It never issues a pass/fail verdict of its own or predicts a failure date.

Why does system_profiler show so little SMART data on Apple Silicon?

macOS's system_profiler only shows a basic SMART status — it does not surface Percentage Used or Data Units Written. That is a limit of that command, not of the drive: a current smartmontools can read the internal Apple-Silicon NVMe health log directly (observed with smartmontools 7.5 on an Apple-silicon Mac), though exposure varies by Mac and macOS version. External enclosures are the opposite case — the bridge chipset decides what passes, and with a USB bridge that can be the reason an external drive reports no SMART status; over Thunderbolt a drive has a better chance of being read natively.

What this tool will never do

It will never issue a verdict of its own — it will not call your drive "failing", "genuine", or "counterfeit", and it will never give you a failure date, because SMART data alone cannot honestly produce one. When the drive itself declares failure — a FAILED self-assessment, or an attribute marked FAILING_NOW — the decoder shows you the drive's own declaration, clearly labelled as the drive's, not its. Drive health is a trend you watch, not a verdict. This decoder reports the numbers, explains them, and flags the attributes a published source defines as warning signs. That's the same honest posture CoreGuard takes in the app: it observes and explains, and every hardware-danger warning is free.