File to Base64

Base64 takes bytes three at a time and rewrites them as four characters from a fixed set of 64 — the letters in both cases, the digits, plus and slash — with one or two equals signs at the end when the input does not divide neatly by three. It exists because much of the internet was built to move text: email bodies, JSON, XML, HTTP headers, YAML config. Push raw bytes through any of those and something along the way mangles them. Dressing the bytes up as ordinary characters means they arrive intact and can be turned back at the far end, at the cost of carrying more of them.

Four characters for every three bytes is a fixed ratio, so the text is always longer, and that is arithmetic rather than waste. Padding adds a character or two on top. The growth compounds where people forget to look: put the string in JSON and the transport counts the larger figure, store it in a text column and the database stores the larger figure, attach it to an email and the limit applies to the encoded size. If you need it smaller, compress the file and encode the compressed result — the other order gains far less, because encoded text leaves a compressor very little to find.

No, and the confusion does real damage. There is no key and no secret — the alphabet is published, every language ships a decoder, and reversing the string is one step anyone can take. An API key or password stored Base64-encoded is hidden from a passing glance and from nothing more determined. Kubernetes secrets are the classic trap, stored as Base64 by default and routinely mistaken for encrypted ones. Encode when a channel needs text; encrypt when something needs to stay private. The two answer different questions, and encoding is not a weaker form of encryption.

No. The reading happens inside the browser and there is no upload step in the tool at all — no request carries the contents, and no server holds a copy for you to worry about later. The encoded string lives in the page's memory and nowhere else: it is not written to storage, it is not put in the address bar, and refreshing or closing the tab loses it. Copy takes the complete string from that same memory rather than from what is drawn on screen. The distinction matters for what people usually bring here, which is more often a signed document or a credential than a holiday photo.

Nearly always the string rather than the file. The commonest cause is leaving the data: prefix in front of a payload when the decoder wanted the payload alone — those letters decode as bytes and the file header is wrong from its first character. Next is stray whitespace, since a string copied from a wrapped email or a terminal arrives with newlines and strict decoders refuse them. Then missing equals padding, which some decoders demand and others tolerate. Then hyphens and underscores from a URL-safe string fed to a standard decoder. And when you decode back, the bytes carry no name — the extension you save under is what decides how it opens.

In CSS, for small icons and simple SVGs, it is a fair trade: one fewer request, and the image arrives with the stylesheet. Past that it turns against you. An inlined image cannot be cached separately, so every change to the stylesheet re-sends the picture with it, and nothing downloads in parallel because the bytes sit inside a file that blocks rendering. A large photograph inlined this way is a mistake every time. In email, check before you rely on it: several clients, Gmail among them, will not render a data URI image, so an inlined logo shows as nothing at all.

Standard Base64 uses plus and slash, and both mean something else in a URL — a slash separates path segments, and a plus is read as a space by anything decoding a query string as form data. RFC 4648 therefore defines a URL-safe alphabet using hyphen and underscore in their place, usually with the equals padding dropped. The segments of a JWT are written that way. What the browser produces here is the standard alphabet, so for a URL, a filename or a header you will need to swap those two characters yourself, and be ready to restore the padding before decoding.

Files over 20 MB are refused here, and the sensible ceiling for most uses sits well below that. The encoded value is one long string held in memory, so multi-megabyte values make editors, log viewers and browser tooling sluggish. Many APIs cap a request body at a few megabytes and apply that cap to the encoded size, which is the larger figure. Email catches people the same way: a 24 MB attachment against a 25 MB limit fails, because what travels is the Base64 version. Where a file is genuinely large, send a link to it instead — inlining only pays when fetching separately would cost more.