Base64 Size Calculator

Frequently Asked Questions

How much larger is base64 than the original data?

Base64 encodes every 3 bytes into 4 ASCII characters, so the encoded size is ceil(bytes ÷ 3) × 4. That is a ~33% size increase before any line breaks - 900 bytes becomes 1,200 characters.

Why is the formula ceil(bytes/3)×4 instead of just bytes×4/3?

Base64 works in 3-byte groups, and any leftover 1 or 2 bytes still produce a full 4-character block padded with "=". The ceiling on bytes ÷ 3 accounts for that partial final group, so 1 byte still encodes to 4 characters.

What overhead does a data URI add?

A data URI prepends a header like "data:image/png;base64," (about 22 characters plus the MIME type) to the encoded payload. So total length ≈ header length + ceil(bytes ÷ 3) × 4.

When is base64 worth the size penalty?

Inlining tiny assets as data URIs saves an HTTP round-trip, which can beat the ~33% size cost for small icons under a few KB. For large files the inflation and loss of caching usually outweigh the saved request.

Provided by AllCalculators.io
Free online calculators for everyday. No registration required.

Estimates for informational purposes only.

Important Disclaimer: Estimates for informational purposes only.

This calculator provides estimates for informational purposes only. Results are based on assumptions and may not reflect actual outcomes. Consult qualified professionals in relevant fields before making important decisions based on these results.

JavaScript is required to use the interactive calculator above. The questions and answers below remain readable without JavaScript.

How This Calculator Works

Base64 is the encoding that lets you carry arbitrary binary data - an image, a PDF, a signed token - safely inside a text-only channel such as JSON, an HTTP header, an email body, or a CSS file. The catch is that it is not free: every three raw bytes become four printable ASCII characters, so the encoded payload is always larger than the original. This calculator turns that rule into exact numbers. In encode mode you enter a payload size in bytes, kilobytes, or megabytes and it returns the encoded length, the percentage overhead, and - if you tick the data-URI option - the extra characters added by the data:<mime>;base64, prefix. In reverse mode you paste the length of a base64 string and it tells you the maximum number of bytes that string can decode to, which is handy when you only have the encoded blob and need to size a buffer or a database column.

Formula / Method

The encoded length in characters is ceil(bytes ÷ 3) × 4. The ceil matters because base64 pads incomplete final groups with = so the output is always a multiple of four. The theoretical overhead is therefore 4 ÷ 3 − 1 ≈ 33.3%, but for very small payloads the padding pushes it higher. A data URI adds a fixed prefix of data: + the MIME type + ;base64,, so the total characters = encoded length + prefix length. The reverse operation assumes a fully padded string: decoded bytes = (base64 length ÷ 4) × 3, which is the maximum - one or two trailing = signs mean the true payload is 1 or 2 bytes smaller. We require the entered length to be a multiple of 4, because any other value is not a valid canonical base64 string.

Worked Example

Take a 100 KB PNG - 100 × 1024 = 102,400 bytes. Encoded length = ceil(102,400 ÷ 3) × 4 = ceil(34,133.33) × 4 = 34,134 × 4 = 136,536 characters ≈ 133.3 KB, an overhead of about 33.3%. If you inline it as a data URI the prefix data:image/png;base64, adds 22 characters, giving 136,558 total. So inlining that one image into your HTML or CSS costs you roughly a third more bytes over the wire (before gzip, which claws some of it back). In reverse: a base64 string 136 characters long decodes to at most (136 ÷ 4) × 3 = 102 bytes - useful when you receive a token and want to bound its real size.

Common Mistakes

Assuming a flat 33% overhead for tiny payloads - padding makes a 1-byte input expand to 4 characters, a 300% overhead.

Forgetting the data-URI prefix when budgeting an inlined asset - the data:<mime>;base64, header is real bytes on every request.

Confusing bits and bytes - this tool works in bytes; divide network bit-figures by 8 first.

Treating the reverse figure as exact - trailing = padding means the decoded size can be 1 or 2 bytes less than the maximum.

Ignoring that gzip/brotli compress base64 text well - the on-the-wire cost after compression is usually far below the raw 33%.

Tips & FAQ

Should I inline images as data URIs? For small icons and below-the-fold assets it can save a round trip, but the base64 cost plus loss of caching usually makes separate files better above a few kilobytes. Why is my encoded string not a multiple of 4? Then it is URL-safe base64 with padding stripped, or it is truncated - canonical base64 is always a multiple of 4. Does newline wrapping change the size? MIME base64 inserts a line break every 76 characters, adding roughly 1.3% more; this calculator reports the unwrapped length. What about base64url? It swaps +/ for -_ and often drops padding, but the byte-to-character ratio is identical. Is base64 encryption? No - it is reversible encoding with no secret, so never treat a base64 string as protected. How big can a data URI be? Browsers and servers cap URL and header lengths; very large data URIs (hundreds of KB) can hit limits, so prefer real files for big assets. Use this tool to budget payload sizes before you commit to inlining.

Frequently Asked Questions

Related Developer Tools Calculators