Exact vs. Estimated vs. Unknown File Size — What NSFWDL's Size Labels Mean

What Exact actually means

Exact means NSFWDL has an authoritative byte count for that specific format. The count can come from the source extractor's hard filesize metadata, or from NSFWDL's own probe when an HTTP Range response confirms the total through Content-Range (or a real GET returns a trustworthy Content-Length). It is not a bitrate calculation or a HEAD-only length, and the live transfer remains the final authority if the source changes what it serves.

What Estimated actually means

Estimated is not a guess pulled from nowhere — it is real evidence that stops short of an authoritative total. It can come from the extractor's approximate filesize metadata, a HEAD-only Content-Length, or a bitrate-times-duration calculation. A HEAD response is treated as medium-confidence because that server path can differ from the real download; bitrate calculations are lower-confidence because actual files do not always hold a constant bitrate.

What Unknown actually means

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.

Why your file manager can show a different number

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.

Why segmented streams (HLS/DASH) are harder to size in advance

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.

Further reading

Decimal (MB, base-1000) and binary (MiB, base-1024) byte prefixes are formally defined by NIST's public reference on binary multiples (physics.nist.gov/cuu/Units/binary.html), if you want the standards-body definition rather than NSFWDL's own explanation above.