Whole-byte reconciliation railLive expected, received, and tolerance boundaries
The exact table below is the accessible numeric equivalent of this visual.
Unit Converters
Data Transfer Tolerance Calculator
Normalize expected and received payload sizes to exact whole-byte counts, build an asymmetric tolerance interval from percentage or absolute allowances, identify missing or excess bytes, and keep the size decision separate from the reported cryptographic-hash result.
TRANSFER RECONCILIATION
Test a received byte count against an explicit tolerance rule
Use this page when a manifest, backup job, object store, replication task, or delivery record provides an expected size and a separately observed received size. The calculator normalizes both quantities to whole bytes before applying the rule.
Decision boundary: percentage tolerances are calculated from the expected byte count; absolute tolerances use their own declared unit. Size status is inclusive at the effective whole-byte limits. A hash mismatch overrides size agreement, while an unchecked hash leaves content integrity unverified.
Decision—
Signed byte variance—
Received / expected—
Effective lower limit—
Effective upper limit—
Absolute difference—
Size-band status—
Hash-evidence state—
Exact byte-count match—
BYTE-COUNT TOLERANCE
See the received payload against the permitted whole-byte interval
The orange rail is the entered tolerance band after unit normalization and integer-boundary resolution. The expected and received markers remain separate so a near match cannot masquerade as an exact match.
| Element | Exact bytes | Difference from expected | Decision role |
|---|
| Quantity | Entered value | Bytes per unit | Canonical bytes |
|---|
| Priority | Observed condition | Reported outcome |
|---|
HOW TO USE
Reconcile one declared transfer without erasing its evidence
- Enter the expected payload quantity exactly as recorded in the manifest, source object, backup index, or delivery specification.
- Choose the expected unit explicitly; do not relabel a binary GiB value as decimal GB.
- Enter the independently observed received quantity and its own unit.
- Select a percentage or absolute tolerance and preserve shortfall and excess allowances separately.
- Report whether a separate cryptographic-hash comparison was not checked, matched, or mismatched, then read the decision together with the byte ledger.
TRANSFER FUNDAMENTALS
Six quantities govern the result
CALCULATION METHOD
Normalize units, resolve integer limits, then apply decision precedence
E = expected × unit factorR = received × unit factorΔ = R − EL = ceil(E − shortfall allowance)U = floor(E + excess allowance)Size is within tolerance when L ≤ R ≤ U. Hash mismatch is reported before size acceptance; a declared hash match with unequal byte counts is reported as conflicting evidence.
DECIMAL AND BINARY UNITS
MB and MiB describe different byte counts
Decimal prefixes use powers of 1,000: 1 MB is 1,000,000 bytes and 1 GB is 1,000,000,000 bytes. Binary prefixes use powers of 1,024: 1 MiB is 1,048,576 bytes and 1 GiB is 1,073,741,824 bytes. The calculator converts each entered quantity through its selected factor before comparing them, so a label mismatch becomes visible rather than being absorbed into the tolerance.
WHOLE-BYTE DOMAIN
A payload size is a count, not a continuously divisible measurement
The canonical values must resolve to whole bytes and remain within JavaScript’s safe-integer range. Percentage tolerances may create fractional mathematical boundaries, but a received file cannot contain a fractional byte. The lower effective limit is therefore rounded upward and the upper effective limit downward before the inclusive comparison.
ASYMMETRIC TOLERANCE
Missing bytes and extra bytes are not automatically equivalent
A shortfall can indicate truncation, omitted records, failed blocks, or an incomplete restore. An excess can indicate appended metadata, padding, encapsulation, or a mismatched object. The calculator keeps the two allowances independent because a workflow may permit one condition while prohibiting the other. The entered tolerance is a project rule, not a universal networking standard.
INTEGRITY GATE
Size agreement does not prove content identity
Two objects can have the same length while containing different bytes. NIST’s Secure Hash Standard defines message digests for detecting whether messages changed; this page records only the reported comparison state and does not compute a digest. A mismatch is an integrity failure. “Not checked” leaves integrity unresolved even when the byte count lies inside the selected interval.
DETAILED CALCULATION PROCESS
Default substitution and reconciliation
| Symbol | Meaning | Default | Canonical interpretation |
|---|---|---|---|
| E | Expected payload | 1024 MiB | 1,073,741,824 B |
| R | Received payload | 1023.5 MiB | 1,073,217,536 B |
| tl | Allowed shortfall | 0.1% | 1,073,741.824 B before integer-boundary resolution |
| tu | Allowed excess | 0.1% | 1,073,741.824 B before integer-boundary resolution |
| H | Hash evidence | Not checked | Integrity remains unverified |
- Convert 1024 MiB × 1,048,576 B/MiB = 1,073,741,824 B.
- Convert 1023.5 MiB × 1,048,576 B/MiB = 1,073,217,536 B.
- Compute each 0.1% allowance as 1,073,741.824 B.
- Resolve the lower limit as ceil(1,073,741,824 − 1,073,741.824) = 1,072,668,083 B.
- Resolve the upper limit as floor(1,073,741,824 + 1,073,741.824) = 1,074,815,565 B.
- Compute Δ = 1,073,217,536 − 1,073,741,824 = −524,288 B.
- Confirm that the received count is inside the effective interval.
- Report “size within tolerance; content integrity not verified” because no hash comparison was supplied.
RESULT INTERPRETATION
Read the signed variance before the headline status
A negative variance means the received object is smaller; a positive variance means it is larger. Completeness is a quantity ratio, not a statement about semantic completeness. An exact count match is stronger size evidence than a tolerance match, but neither proves authenticity, ordering, parseability, or content identity. If the decision says “evidence conflict,” investigate the provenance of both the byte count and hash result instead of choosing whichever result is more convenient.
IAN / XIAOHEI EXPLAINER
The scale and the stamp answer different questions
The balance scale represents quantitative reconciliation: how many bytes were expected and received, and whether the difference fits the declared interval. The separate stamp represents content-integrity evidence. Xiaohei can balance the crates and still cannot issue the stamp without a separate check.
EVIDENCE AND DATA LINEAGE
Retain the record behind every field
Keep the manifest or source-object identifier, expected-size acquisition method, received-size acquisition method, timestamp, host or storage service, transfer tool and version, protocol, retry count, packaging state, compression or encryption state, selected unit definitions, entered tolerance authority, hash algorithm, both reported digests, and operator or automated-job identity. Record whether the size refers to logical payload, stored object, archive, encrypted object, or transmitted wire quantity.
LIMITS AND EXCLUSIONS
What this model does not establish
- It does not compute or validate a cryptographic digest.
- It does not prove file authenticity, authorization, confidentiality, or provenance.
- It does not inspect archive members, record counts, database consistency, packet loss, retransmission, or application-level parsing.
- It does not decide whether protocol headers, checksums, replicas, parity, compression, or encryption are included in either size.
- It does not supply a universal acceptable tolerance; the entered interval must come from the governing workflow.
- It does not make unsafe integer counts reliable beyond the supported numeric domain.
WORKED DECISION CASES
How the same byte evidence leads to different outcomes
Backup restore screening
A manifest expects 20 GiB and the restored object is 19.999 GiB. A 0.01% shortfall allowance may place the count inside the planning interval, but an unchecked hash leaves the restored content unverified. The correct outcome is provisional, not “backup accepted.”
Artifact delivery conflict
A delivery record reports a matching digest while the observed byte count differs by one byte. The page reports conflicting evidence because identical full-file content and unequal length do not form a coherent record. Reacquire both values and confirm exactly which object was hashed.
TECHNICAL GLOSSARY
Terms used in the calculation record
- Byte
- A data-quantity unit used here as the canonical whole-number count.
- Decimal prefix
- A power-of-1,000 multiplier such as kB, MB, or GB.
- Binary prefix
- A power-of-1,024 multiplier such as KiB, MiB, or GiB.
- Manifest
- A controlled record describing expected transfer objects and attributes.
- Variance
- Received bytes minus expected bytes, retaining direction.
- Tolerance interval
- The entered inclusive lower-to-upper range after whole-byte resolution.
- Message digest
- A fixed-length result from a hash algorithm used as evidence of message change.
- Evidence conflict
- A state in which reported observations cannot be interpreted coherently without investigation.
Frequently asked questions
Why does the calculator reject half a byte?
A payload size is a count of bytes. The selected value and unit must resolve to a whole count before the tolerance comparison can be audited.
Does 1 GB equal 1 GiB?
No. 1 GB is 1,000,000,000 bytes, while 1 GiB is 1,073,741,824 bytes.
Can I use zero tolerance?
Yes. Zero shortfall and zero excess require an exact byte-count match, although content integrity still requires separate evidence.
Are boundary values accepted?
Yes. The effective lower and upper whole-byte limits are inclusive.
Why can a hash mismatch override a size match?
Equal length does not guarantee equal content. A reported digest mismatch is direct evidence that the compared messages changed or that the evidence was collected incorrectly.
Why is a reported hash match with unequal sizes called a conflict?
The two observations do not describe a coherent full-object comparison. Confirm the object boundaries, algorithm, digest source, and size acquisition method.
Should protocol overhead be included?
Only if both expected and received quantities use the same declared boundary. Do not compare logical payload bytes with wire bytes without a separate reconciliation.
What tolerance should I enter?
Use the value approved by the governing transfer, storage, backup, delivery, or validation procedure. This calculator does not invent that policy.
AUTHORITATIVE BASIS
Unit definitions and integrity language
- IEC 80000-13:2025 — quantities, units, and binary prefixes for information science and technology.
- NIST Guide to the SI, Chapter 4 — decimal SI prefix factors and the distinction from binary powers.
- NIST FIPS 180-4 Secure Hash Standard — secure hash algorithms and message digests used to detect message changes.