NSFWDL never shows a size it can't back up with real evidence. This guide explains exactly what Exact, Estimated, and Unknown mean, and why the number in your file manager can look different from the one NSFWDL showed before you downloaded.
Exact is only used when a real network response confirmed the total size — not because a source claims a number and NSFWDL trusts it. That confirmation happens one of two ways: the source's own extraction metadata states a hard byte count for that specific file, or NSFWDL's own probe sent an HTTP Range request for the file and the source answered with a Content-Range header stating the real total (or, less commonly, a plain GET returned a trustworthy Content-Length). Either way, Exact means a transfer-shaped request actually got a transfer-shaped answer.
Estimated is not a guess pulled from nowhere — it is real evidence that stops short of a confirmed transfer. Two situations produce it. First: a plain HTTP HEAD request (the lightweight "tell me about this file" request made before committing to a download) returned a Content-Length header, but NSFWDL treats a HEAD-only answer as medium-confidence rather than proof, because the server code path that answers a HEAD request is not always the same one that serves the real download. Second: the source only exposes a bitrate and a duration, and NSFWDL calculates size as bitrate times duration — a real calculation, but real files rarely hold a perfectly constant bitrate, so the number is an approximation.
Unknown means NSFWDL asked and did not get a usable answer — no Content-Length, no Content-Range, nothing it can stand behind. Rather than inventing a plausible-looking number, it shows Unknown honestly. The transfer itself is still measured live as bytes actually arrive, so an Unknown-sized format is not a blind choice; NSFWDL simply has nothing to show before the download starts.
A real example: a file that is exactly 299,984,748 bytes is about 300.0 MB in decimal units (the SI standard NSFWDL always displays, where 1 MB = 1,000,000 bytes) and about 286.1 MiB in binary units (where 1 MiB = 1,048,576 bytes). Same bytes, two correct answers, because they are different units. Some operating systems and browsers compute the binary value but still print the label "MB" instead of the technically correct "MiB" — which is exactly what makes a completed download look smaller than what NSFWDL showed, even though nothing was lost or mismeasured.
NSFWDL deliberately displays decimal MB/GB everywhere rather than mixing in binary units, so its own numbers stay internally consistent even when another tool's labeling does not match.
A direct progressive file — the source serving one continuous file at one URL — can often be probed directly, because it is genuinely one static object with one real answer to "how big is this." An HLS or DASH stream works differently: what actually gets downloaded is a sequence of small segments assembled according to a manifest, and the specific combination of segments a given quality choice will pull is not one file sitting at a knowable size ahead of time. For those, NSFWDL falls back to the same bitrate-times-duration calculation described above and labels the result Estimated rather than Exact. This is a difference in how the source delivers the file, not a judgment about the source's quality.
Decimal (MB, base-1000) and binary (MiB, base-1024) byte prefixes are formally defined by NIST's reference on binary multiples, if you want the standards-body definition rather than NSFWDL's own explanation above.
Each format is graded on its own evidence. A single source can serve one quality as a directly confirmable file and another as a manifest-based stream in the same result, so the label reflects that specific format, not the source as a whole.
No. Estimated means NSFWDL has real evidence behind the number — a HEAD response or a bitrate/duration calculation — just not a confirmed transfer total. Unknown means neither approach returned anything usable, so no number is shown at all rather than a fabricated one.
Exact always reflects a confirmed response from a real network request, not a guess — but a source can still change what it actually serves between that check and a download completing. NSFWDL measures the real transfer as it happens and enforces size limits against that live measurement, not just the earlier label.
The label shown in the format list comes from a check made during extraction. Immediately before a download actually begins, NSFWDL repeats a similar check as a safety step, since a source can change what it serves in the time between those two moments.