File Size Limits: Does Your App Mean MB or MiB?

Before approving a file-size limit in a customer portal, ask for the exact permitted byte count and the unit used to display it. “One megabyte” and “one mebibyte” are different quantities. A rounded label should not be the only definition of what the server accepts.

This is a small but useful part of commissioning file handling. It does not choose a suitable limit for your business, make uploads safe or explain every restriction imposed by your hosting provider.

Give the unit an exact meaning

NIST's reference on binary prefixes provides these explicit comparisons: one megabyte, written MB, is 1,000,000 bytes; one mebibyte, written MiB, is 1,048,576 bytes. It also distinguishes the byte symbol B from the bit quantities shown in its examples.

The two byte totals are not alternative spellings of the same amount. If a specification uses MB but an implementation applies a binary multiplier, the displayed instruction and the enforced rule can disagree.

Choose one convention for the product, document it and use the correct label. Avoid telling a customer that their computer's file display is wrong merely because it uses a different convention or rounds differently. The application should explain its own rule clearly enough for the customer to act.

Store and compare bytes, then format for people

My practical recommendation is to define the size budget as an integer byte count. Derive the help text, validation message and administrative settings from that same agreed value rather than maintaining separate handwritten limits.

Formatting is a presentation decision. A compact file list may show a rounded quantity, while an error message offers a more precise explanation. The comparison that accepts or rejects a file should use the actual byte count, not the rounded display string.

Otherwise two files can appear to have the same displayed size while lying on different sides of the acceptance boundary. That is a reason to improve the message, not to invent a different measurement for each screen.

If administrators can change the limit, specify whether the setting asks for bytes, MB or MiB. Show the interpreted result before saving. Do not silently change an existing setting's meaning when replacing an older label.

Identify what is being limited

A file's byte count is not the same thing as every other size involved in handling it. Your brief should distinguish the original selected file, a processed delivery copy, a collection of attachments and the complete submission request.

For example, resizing an image may create a smaller copy. Decide whether the rule concerns the original, the generated copy or both. That decision needs an explicit workflow; it does not follow from choosing MB instead of MiB.

Similarly, a per-file allowance does not establish that several permitted files will fit within a separate total-submission allowance. Ask the developer to list each applicable limit and its purpose. Where an external service imposes a stricter boundary, verify that service's current documentation instead of assuming your own setting overrides it.

For the wider decisions about permitted formats, review and access, see what to decide before adding uploads. Those decisions remain necessary even when the byte units are consistent.

Make rejection useful rather than mysterious

A helpful proposed message identifies the affected file, states the relevant limit and explains whether the customer needs a smaller file or a different submission route. Avoid reporting a total-request problem as though one particular attachment exceeded its individual allowance.

If a local precheck allows the file but the server refuses it, investigate which limits and byte definitions each layer used. Do not promise success merely because the browser accepted the selection. Client feedback and the server's final acceptance have different responsibilities.

Keep unit wording consistent in help pages, translated interfaces and staff instructions. Translating the surrounding sentence should not change the underlying byte budget. Where a file picker or operating system shows another convention, your own explanation should remain unambiguous.

A boundary test belongs in the handover

Ask for synthetic files whose byte counts are known independently of their rounded labels. Include a file exactly at the allowed boundary, one below it and one above it. Agree whether equality is accepted and check both the browser's feedback and the server's decision.

Also test a group of individually permitted files against any total limit. Confirm that the displayed limit, validation response and administrator setting represent the same quantity. These are proposed acceptance tests, not results from a portal already exercised here.

Bring the exact byte rule and the different size scopes to a web-app planning discussion. NIST supplies the unit definitions; the business allowance, processing workflow and failure messages are decisions for your project. Correct units remove one source of avoidable confusion, not every cause of a failed upload.