The first time I saw a Base64 string, I assumed it was encrypted. It looked like scrambled secrets — SGVsbG8sIFdvcmxkIQ== — and I treated it with the caution of a password. Then someone decoded it in front of me and it said "Hello, World!" I had been intimidated by plain text wearing a costume. Base64 is not encryption at all; it's a translation scheme that turns binary data into plain ASCII text so it can travel through systems that only speak text. This tool encodes and decodes it in both directions, instantly.
What Is Base64?
Many systems — email, JSON APIs, URLs, HTML attributes — were designed for text and choke on raw binary bytes. Base64 solves this by representing any binary data using only 64 safe ASCII characters: A–Z, a–z, 0–9, plus + and / (with = as padding). Three bytes of data become four Base64 characters, which is why encoded output is about 33% larger than the input.
The classic example: "Hello, World!" encodes to SGVsbG8sIFdvcmxkIQ==. Decoding reverses it exactly — no information is lost, because this is a reversible encoding, not a one-way hash and not encryption. There is no key, no secret, no security: anyone who sees a Base64 string can decode it in seconds. Treating Base64 as protection is one of the most common security mistakes in web development.
You'll meet Base64 in HTTP Basic authentication (username:password encoded in the Authorization header), data URLs that embed small images directly in HTML/CSS (data:image/png;base64,...), JWT tokens, email attachments (MIME), and API fields that need to carry binary payloads inside JSON.
How Base64 Encoding Works
The mechanics are straightforward once you see them. Take the input bytes and read them as a stream of bits. Regroup those bits into chunks of 6 (instead of 8), and map each 6-bit value (0–63) to the corresponding character in the 64-character alphabet. If the input length isn't a multiple of 3 bytes, = padding fills the output to a multiple of 4 characters.
| Input | Base64 Output | Notes |
|---|---|---|
Hello, World! | SGVsbG8sIFdvcmxkIQ== | 13 bytes → 20 chars (with padding) |
Hello World | SGVsbG8gV29ybGQ= | 11 bytes → 16 chars |
user:pass123 | dXNlcjpwYXNzMTIz | HTTP Basic auth format |
Man | TWFu | 3 bytes → 4 chars, no padding needed |
Two variants exist beyond standard Base64: Base64URL replaces + and / with - and _ so the output is safe inside URLs and filenames (this is what JWTs use), and it often drops the padding. Decoding must match the variant that encoded the data — feed Base64URL into a standard decoder and you'll get garbage or errors.
How to Use the Base64 Encoder Decoder
Two boxes, two directions, no configuration needed for the common cases.
Step 1 — Paste your input. Put plain text in to encode, or a Base64 string in to decode. The tool also handles file input: encoding a file (an image, a PDF) produces its Base64 text representation.
Step 2 — Choose the direction. Encode converts text or file bytes into Base64; Decode converts a Base64 string back to the original text or bytes. The conversion runs as you type — no submit button.
Step 3 — Handle the output. Copy the encoded string for pasting into code, configs, or data URLs. When decoding, the result appears as readable text; if you decoded file data, download it to restore the original file byte-for-byte.
Step 4 — Round-trip to verify. Feed the output back as input in the opposite direction. If you get your original text back, the encoding is intact — a quick sanity check before embedding a data URL or shipping an auth header.
Common Uses of Base64
Data URLs: embedding small images or fonts directly in HTML/CSS (<img src="data:image/png;base64,...">) eliminates a network request — great for icons, terrible for large photos because of the 33% size inflation.
HTTP Basic Auth: the Authorization: Basic <base64> header carries username:password. It must always travel over HTTPS, since the "encoding" is trivially reversible.
APIs and JSON: binary payloads (file contents, cryptographic signatures, serialized objects) get Base64-encoded to fit inside JSON string fields.
Debugging: developers decode mysterious blobs in logs, tokens, and CTF challenges to see what's actually inside — which is exactly how I learned Base64 isn't encryption.
Who Uses a Base64 Encoder Decoder?
Web developers build data URLs, debug auth headers, and inspect JWT payloads — the daily bread of API work.
Backend engineers encode binary data for JSON transport and decode incoming payloads during integration testing.
Security analysts and CTF players peel layered encodings (Base64 inside hex inside Base64…) to reveal hidden payloads.
Students learn how text encodings work by watching familiar strings transform and transform back.
Key Features
- Bidirectional conversion — encode text/files to Base64 and decode back, instantly.
- Live conversion — output updates as you type, no buttons required.
- File support — encode any file to Base64 text; decode back to the original file.
- UTF-8 correct — non-ASCII characters (emoji, accented text) encode and decode properly.
- Validation — clear errors on malformed Base64 instead of silent garbage.
- Copy and download — one click to copy text output or save decoded files.
- Private and free — everything runs in your browser; your data never leaves your device.
No — and treating it as encryption is a genuine security mistake. Base64 is a reversible encoding with no key; anyone can decode it in seconds. It exists to make binary data safe for text-only channels, not to hide anything. For confidentiality, use real encryption.
Three input bytes become four output characters, so encoded data is about 33% larger. Don't Base64-encode large files for storage — it's a transport format, not a compression format.
A URL-safe variant that uses - and _ instead of + and / (and usually drops padding). JWTs and URL parameters use it. Decode with the matching variant or you'll get errors.
Use the file input: the tool reads the image bytes and produces the Base64 string, ready to embed as a data URL like data:image/png;base64,....
Either the input wasn't valid Base64 (check for typos or truncated strings), or it was encoded with a different variant (standard vs URL-safe). Strict decoders reject invalid characters rather than guessing.
Yes — feed the output back as input repeatedly. Data that's been encoded more than once (common in CTF challenges) peels one layer per decode round.
No. Encoding and decoding happen entirely in your browser — nothing is sent to any server.
Yes — free, unlimited, no account required.