Data URI size calculator

Inlining a font, icon, or stylesheet as a data URI avoids an extra HTTP request, but Base64 encoding inflates the payload by about one third and a data: prefix adds still more characters. It returns the exact Base64 payload length, the full data URI character count, the payload overhead near thirty-three percent, the total overhead including the prefix, and a recommendation to inline or keep a separate link. Successful API calls cost $0.002; invalid input is not billed.

How Base64 data URI size is computed from original bytes

A data URI that carries binary content uses the RFC 2397 form data, then an optional media type, then the token semicolon-base64, then a comma, then the payload. The payload is standard RFC 4648 Base64: every three original bytes become four ASCII characters, so the encoded length is exactly four times the ceiling of the original length divided by three. When the original length is not a multiple of three, padding equals signs fill the last quartet so the payload length is always a multiple of four. Payload-only overhead is therefore about thirty-three percent—exactly one third when the original size is a multiple of three, and a little more when padding is required.

Input contract, response shape, and error behaviour

Ten thousand bytes as the default octet-stream type yields a 13373-character URI and a link recommendation. POST a JSON body with one required field bytes: a positive integer (or numeric string) for the original asset size before encoding. Aliases size, length, n, and byte_count map to the same parameter so bundler scripts and form widgets can keep their local names. Optional media_type (aliases mime, type, content_type, mime_type) is the MIME type written into the prefix; it defaults to application/octet-stream when omitted. Optional budget (aliases max, limit, max_bytes, max_size) is the largest data URI length you still treat as worth inlining and defaults to 2048, a common HTTP/1 rule of thumb. Missing, empty, non-integer, zero, or negative values fail with invalid_input naming the field; a media type that is not type/subtype, or that contains whitespace or a comma, is rejected the same way. Those failures are not billed. On success the body echoes bytes, media_type, and budget; returns prefix and prefix_chars; returns base64_chars and padding_chars; returns data_uri_chars and overhead_chars; returns overhead_percent for the full URI versus the original file and payload_overhead_percent for the Base64 payload alone (the roughly thirty-three percent figure); returns expansion_ratio as data URI length over original bytes; and returns within_budget plus recommendation set to inline or link. Example: 1024 bytes as image/png yields a 22-character prefix, 1368 Base64 characters with two pads, a 1390-character data URI, payload overhead about 33.59 percent, and an inline recommendation against the default 2048 budget. Pair the numbers with your own encoder if you need the string itself; this endpoint never emits the encoded payload.

When inlining a data URI is worth the thirty-three percent overhead

Base64 makes that trade-off worse by about one third, and HTTP/2 or HTTP/3 multiplexing makes a separate request cheaper than it was on HTTP/1, so the break-even size is smaller than many 2012-era blog posts still claim. Bundlers that used an eight-kilobyte url-loader limit were optimizing for HTTP/1 sprites; override budget to 8192 if you are matching that legacy rule, or lower it for HTTP/2 sites. Use it as a gate in a pull-request check: if data_uri_chars exceeds the budget, keep the asset as a URL.