Base64 encode in the flavour your target reads

Because Base64 spends 8 bits of output on every 6 bits of input: it slices the data into 6-bit pieces so that each piece can be one of 64 printable characters, and every group of 3 bytes leaves as 4 characters. That is a fixed 4/3 ratio, or +33.33%, before anything else — a 5 MB file becomes exactly 6,990,508 characters. Padding adds up to 2 characters, line wrapping at 76 columns adds another 91,981 line breaks to that same file, and a data: URI prefix adds the length of the media type on top. The overhead is the price of moving bytes through a channel that only promises to carry text.

Use URL-safe when the string will sit in a URL, a filename or a cookie, and standard everywhere else. The two differ in exactly two characters out of 64: RFC 4648 §4 ends its table with + and /, while §5 substitutes - and _ for them. Those two are the ones that break in transit — + is decoded as a space by form parsers, and / cuts a value in half when it lands in a path segment. Both alphabets decode back to identical bytes, so the choice is about the channel, never about the data.

Turn it off when the consumer is a JWT, a URL or anything that would have to percent-encode the = as %3D. RFC 7515, which defines the JSON Web Signature format, requires base64url with the padding omitted, and most modern web APIs follow it. Keep the padding for MIME, for PEM and for older libraries, some of which raise an error on an unpadded string rather than working the length out for themselves. The padding carries no data either way: it only rounds the last group up to four characters.

Because it is 4 bytes before it is anything else. Base64 encodes bytes, not letters, so text is converted to UTF-8 first: 😀 is F0 9F 98 80, four bytes, which fill one full group of 4 characters and start a second, giving 8J+YgA== — 8 characters. The same arithmetic explains the rest of Unicode: café is 5 bytes and comes out as Y2Fmw6k=, 東京 is 6 bytes and comes out as 5LiW55WM with no padding at all. Anything that encodes text through the browser's raw btoa() instead throws on those inputs, because btoa refuses any character above U+00FF.

Only when a MIME parser is on the other end. RFC 2045 caps an encoded body at 76 characters per line and expects CRLF endings, which is why mail attachments look the way they do; PEM, defined by RFC 7468, uses 64 instead and wraps its payload in BEGIN and END lines. HTTP headers, JSON fields, database columns and data: URIs all want one unbroken line, and a stray newline inside a data: URI truncates it as far as the CSS or HTML parser is concerned. That is why switching this page to data: URI output turns wrapping off and keeps it off.

Encode the file, tick “data: URI”, and paste the result where a URL would go. The output takes the form data:image/svg+xml;base64,PHN2Zy… — the media type comes from the file the browser reported, from its extension when the browser says nothing, and from the shape of the text when you typed it in. Inlining is a real trade for small assets: it removes a request but adds 33% to the bytes and the asset can no longer be cached on its own, so icons and 1 KB SVGs usually win while photographs do not.

Nine times out of ten because the shell added a newline your text did not have. echo "hello" | base64 gives aGVsbG8K, where the trailing K is the encoded 0A; printf 'hello' | base64 gives aGVsbG8= instead. The other cause is wrapping: GNU coreutils breaks its output at 76 columns unless you pass -w 0, macOS's base64 emits one line unless you pass -b 76, and openssl base64 wraps at 64. Same bytes, different presentation — decode both and they agree.