Free Base64 Encoder & Decoder Online

What Is Base64 Encoding and How Does It Work

Base64 is a way of writing binary data using only 64 printable ASCII characters: the letters A to Z in both cases, the digits 0 to 9, plus the symbols + and /, with = used as padding at the end. This encoder and decoder moves text, files, and images into that alphabet and pulls them back out again. Developers reach for it constantly. Anyone debugging a JWT, embedding a small icon straight into a stylesheet, inspecting a MIME email attachment, or pushing a file through a JSON field is looking at Base64 whether they realise it or not. Being able to flip a string back to readable form in a second, without installing anything or trusting a paste to a remote service, saves a surprising amount of time during a debugging session. The transform is pure arithmetic on bits, not compression or encryption. Three input bytes make 24 bits; those 24 bits are re-sliced into four groups of 6 bits; each 6-bit group is a number from 0 to 63 that indexes the Base64 alphabet and becomes one output character. Three bytes in, four characters out, every time — which is exactly why encoded output runs about 33% larger than the source. When the input length is not a multiple of three, the final group is zero-filled and one or two = characters are appended so decoders know how many real bytes to keep. Decoding reverses the process: map each character back to its 6-bit value, glue the bits together, and read them off as bytes. Text is treated as UTF-8 first, so a rupee sign or an emoji becomes its multi-byte sequence before any encoding happens. Try it with the string Helperzy 2026. That is 13 bytes in UTF-8, so it splits into four full groups of three bytes with one byte left over. Each full group produces four characters, and the leftover byte produces two characters plus two = signs to fill the gap. The finished result is SGVscGVyenkgMjAyNg==. Notice the length: 13 bytes became 20 characters, the 33% overhead in action. Paste that string into the decoder and you get Helperzy 2026 back, byte for byte. Now damage it deliberately by deleting the final = characters. Strict decoders reject the string because the padding no longer matches the bit count, and you get an error instead of output. Restore the padding and it decodes cleanly again. That round trip is worth doing once by hand, because it makes the padding rules stop feeling arbitrary. Four situations come up again and again. A backend engineer receives an API error mentioning a token and pastes the middle segment of the JWT here to read the payload claims, spotting an expired exp value in a few seconds. A front-end developer converts a 2 KB SVG spinner into a data URI and inlines it in CSS, removing one HTTP request from the critical path. A support engineer digs a base64-encoded PDF out of a webhook log, decodes it back to a file, and opens it to confirm the customer really did receive a blank invoice. A QA tester builds a request fixture that carries a small sample image inside a JSON body, encoding it once and pasting the string into the test file. None of these need a library or a terminal, which is the point. One pitfall trips up almost everyone: Base64 is not security. It looks scrambled, so people assume it hides something, then commit an encoded password to a repository. Any decoder undoes it in a second with no key involved. Use real encryption when you need secrecy and treat Base64 purely as a transport format. Two smaller gotchas: standard Base64 contains + and /, both of which have their own meaning inside a URL, so use the URL-safe variant with - and _ when the value goes into a query string or filename; and inlining a large image as a data URI can slow a page down more than the extra request it saved. Everything here runs in your browser, nothing is uploaded, so even a real token stays on your machine.

Learn More — Base64 Encoder / Decoder Guide

🔥 Trending Tools