Convert MB to B

A megabyte is a million bytes. Storage manufacturers have always used this decimal meaning, which is why their capacities look larger than what a computer reports.

A byte is eight bits, though that was not always fixed — early machines used six, seven or nine. The eight-bit byte won because it holds one character of text and divides neatly in half.

Going from megabytes to bytes moves the decimal point 6 places to the right and changes nothing else. There is no factor to remember and no rounding to decide: the digits stay in the same order and only their position changes.

1,234 MB is 1234000000 B — same digits, moved along. That is worth knowing because it is the one kind of conversion you can check at a glance: if the digits of the answer are not the digits you started with, something other than the conversion has happened to them.

Configuration formats that take a size almost always take an integer of bytes, and the reason is that every other unit in this area is ambiguous. A byte is the same quantity in every system and under every convention; a megabyte is 1,000,000 to a standards body and a network engineer and 1,048,576 to a great deal of software. A field defined in bytes cannot be misread, which is exactly why it is defined that way.

The conversion out of decimal megabytes is a multiplication by a million. 1 MB is 1000000, 10 MB is 10000000, 50 MB is 50000000 and 512 MB is 512000000. Every one of those is a round number in the system this page uses, and every one of them is an awkward number in binary units — which is the first clue to what somebody meant when you find 52428800 in a file.

The same field that accepts 10000000 will frequently accept 10M, and the suffix is not shorthand for the digits. nginx reads k as 1,024 and m as 1,048,576, so client_max_body_size 10m is 10,485,760 bytes. PHP does the same for upload_max_filesize, post_max_size and memory_limit, where K, M and G are all powers of 1,024. The GNU tools draw the distinction explicitly: M means 1,048,576 and MB means 1,000,000, and they are separate suffixes.

The gap is 4.9 per cent at megabyte scale, which is small enough to survive review and large enough to matter at a boundary. It is also invisible in the file: 10M and 10000000 look like the same intent and are 485,760 bytes apart. Where a config accepts both forms, pick one convention for the whole file and say so at the top of it, so that the next person editing the number does not have to work the question out again.

The value to write is the one that will look right in the tool that reports on it. If the dashboard, log line or error message the team looks at renders sizes in mebibytes, then 10485760 shows as a clean 10 MiB and 10000000 shows as 9.54 — a number that looks like somebody made a mistake. If the surrounding documentation, the customer-facing limit and the marketing page all say 10 MB, the decimal figure is the one that keeps them in agreement.

What does not work is picking one at each site independently. A stack where the proxy is set to 10485760 and the application to 10000000 has a 485,760-byte window in which a request passes the first check and fails the second, and the error that comes back will be the application error rather than the clear rejection at the edge. Consistency across the path matters more than which of the two numbers is chosen.

A file upload usually crosses at least three configured ceilings: a reverse proxy or load balancer body limit, a runtime or application-server limit, and a framework or storage-side limit inside the application. Each is set separately, often by different people at different times, and the smallest one decides what actually happens. Raising the value everybody knows about and leaving the other two is the most common reason a limit change has no visible effect.

Where they fire changes the experience as well as the outcome. An edge rejection arrives quickly and cleanly, often before the body has finished uploading; an application-level rejection arrives after the whole file has been transferred, which on a slow connection is minutes of waiting for a failure. Setting the edge limit slightly above the application limit means the useful error is the one users see.

A limit applies to the request body, and the request body is larger than the file. Multipart form data wraps each part in a boundary line and a set of headers, which is a fixed cost of a few hundred bytes per field and negligible for a large file. Base64 is not negligible: it turns every three bytes into four printable characters, so a file carried inside a JSON document grows by about 33 per cent, and a 10 MB file arrives as roughly 13.4 MB of body.

So a limit intended to accept 10 MB files should be set from the encoded size rather than the file size. For multipart, a few hundred kilobytes of headroom is plenty. For base64 in JSON, multiply by 4/3 and add a margin: a limit of 14000000 accepts a 10 MB file comfortably, while 10000000 rejects anything over about 7.5 MB and produces a bug report that says the limit is wrong.

A bare 52428800 in a config file is a number nobody will verify, and a wrong one is indistinguishable from a right one at a glance. Where the format permits an expression, write 50 1024 1024 and let the reader see the derivation. Where only a literal is allowed, put the working in a comment on the line above: the intended size, the system it is in, and the tool the value has to agree with.

It is also worth recording where the number came from. A limit that exists because a customer contract says 50 MB is a different thing from one that exists because a memory profile said so, and the two will be changed for different reasons. Config values with no stated origin tend to be either raised carelessly or defended forever, and a single sentence in a comment prevents both.

When a request is refused for size, most systems report the configured limit and many report the size received, both in bytes. That pair of numbers is the fastest diagnosis available: it identifies which layer rejected the request, because the limit quoted will match exactly one of the values in the stack, and it confirms whether a shorthand suffix was interpreted as you expected.

A limit reported as 10485760 when the file says 10000000 means the suffix was read in binary units; a limit reported from a layer you did not know was configured means the ceiling is not where you thought. Both are findable in one line of an error log, and both are much harder to work out from the outside by uploading progressively larger files until something breaks.