Base64 Encoder & Decoder
Instantly encode or decode Base64 strings. All processing happens locally.
What is Base64 Encoding?
Base64 is an encoding scheme used to represent binary data in an ASCII string format. It is commonly used by developers to embed image data within CSS, securely transfer data in URLs, or transmit payloads in JSON Web Tokens. Our tool translates your standard text into a Base64 string instantly.
100% Local Processing
ZeroServer utilizes your browser's native btoa() and atob() functions. This means your text is encoded and decoded in real-time on your device, without ever hitting a database.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Embedding a small PEM certificate or key blob in a YAML file, where the surrounding tooling only accepts a single-line value.
- Reading a Basic auth header out of a captured request to confirm which account a failing integration is actually using.
- Moving a binary fixture through a channel that only carries text — a JSON field, an environment variable, a webhook body.
- Decoding the data URI from a stylesheet to find out what an inlined asset really is and how much weight it adds.
- Confirming a blob you were sent is genuinely Base64 before treating a decode failure as a transport problem.
How it works in practice
A worked example
An integration keeps failing for one account whose password has accented characters in it, and you need the exact header value the client should be sending.
maría:pässwörd
bWFyw61hOnDDpHNzd8O2cmQ=
Fourteen characters came out as twenty-four. Encoding happens over bytes rather than characters, and í, ä and ö each need two bytes in UTF-8, so what goes in is seventeen bytes long before anything is encoded. Seventeen is not divisible by three, which is why the result carries a single = at the end: the last group of four characters is carrying two real bytes instead of three. Put Basic and a space in front of that string and you have the header value, byte for byte.
The edge case that catches people
Run btoa on the same string in a browser console and you get bWFy7WE6cORzc3f2cmQ=, which is four characters shorter and completely different. That function is defined over Latin-1: it maps every code point to exactly one byte, so í becomes one byte where UTF-8 needs two. Above U+00FF it gives up and throws InvalidCharacterError, which is at least loud about it — the range that quietly ruins an afternoon is accented Latin text, where it returns a value your server decodes into mojibake. This page converts to UTF-8 first, which is what an HTTP client actually does.
When not to use this tool
This is a transport encoding, so it is the wrong choice for storage and the wrong choice for size. A column full of it cannot be searched or indexed on what it contains, and inlining an image into a stylesheet costs a third more bytes than the file itself while giving up the separate cache entry the browser would otherwise have kept. If the aim is to keep a value away from whoever can read the page or the network, the word for that is encryption, and nothing here does any.
Frequently Asked Questions
- Is Base64 a form of encryption?
- No. Base64 is encoding, not encryption — it doesn't protect your data. Anyone can decode a Base64 string instantly. Use it only to represent binary data as ASCII text (e.g. embedding images in CSS or data URIs).
- What's the difference between standard Base64 and Base64URL?
- Standard Base64 uses + and / which break in URLs and filenames. Base64URL replaces + with - and / with _, making it safe for query strings, JWT tokens, and file names without percent-encoding.
- How do I encode a binary file (not just text) to Base64?
- Drop the file onto the input area. The tool reads it as binary and produces a Base64 data URI (data:type/subtype;base64,...) suitable for embedding in HTML img src or CSS background-image.
- What are the = padding characters at the end of Base64?
- Base64 encodes 3 bytes at a time. When the input length isn't divisible by 3, = padding fills the last group to keep the output a multiple of 4 characters. Some implementations omit padding — the decoder here accepts both.
- Why does my decoded Base64 look like garbled characters?
- Base64 encodes raw bytes, not text. If the original was a binary file, decoding to a text string will look garbled — the bytes are correct but must be interpreted as the original format, not a UTF-8 string.
- Why is the encoded length always a multiple of four?
- Because three input bytes map to four output characters, and padding fills the final group. That is also why the `=` characters carry no data — they only record how many bytes the last group actually held.
Common errors and gotchas
- Pasting a Base64URL string into a standard decoder. The `-` and `_` characters are not in the standard alphabet, and it fails on the first one it meets.
- Line breaks from a PEM file or a folded mail header. Most decoders tolerate them and some reject them, so strip them before comparing two blobs byte for byte.
- Assuming the decoded result is text. If the original was a PNG you get bytes rendered as replacement characters, which looks like corruption but is not.
- Expecting the output to be smaller. Four characters carry three bytes, so it always grows by roughly a third.
- Losing the trailing `=` when a value passes through something that trims it. Some decoders then refuse the string outright.