Base64 Encoder & Decoder
100% private — runs on your device, never uploaded. Works offline once loaded.
Encode plain text to Base64 or decode Base64 back to readable text. Everything runs locally in your browser.
How Base64 turns bytes into text
Base64 encoding groups raw binary data into 3-byte (24-bit) chunks and re-maps each chunk into four characters drawn from a 64-character alphabet of A–Z, a–z, 0–9, plus '+' and '/'. Because 64 is 2^6, each output character carries exactly 6 bits of the original data, which is why the encoded text is always safe to store or transmit through systems that only understand printable ASCII. When the input length isn't a clean multiple of 3 bytes, one or two trailing '=' padding characters are added to fill out the final group.
This is encoding, not compression or encryption — the output is roughly 33% larger than the input, and anyone can decode it back instantly with no key or password required. Its entire job is compatibility: making binary-safe data survive transport through text-only channels.
Where Base64 quietly does its job
You'll run into Base64 constantly without noticing it. Email attachments are Base64-encoded as part of the MIME standard because raw binary can't travel reliably through SMTP. Images are often embedded directly in CSS or HTML as data: URIs (data:image/png;base64,...) to avoid an extra network request. The header portion of every JWT authentication token and the credentials in an HTTP Basic Auth header are both Base64 under the hood.
- Embedding small icons or logos directly inside CSS/HTML instead of separate files
- Passing binary data (images, files, keys) safely inside JSON payloads
- Decoding the payload of a JWT to inspect its claims during debugging
- Reading Basic Auth credentials sent in an Authorization header
Standard vs. URL-safe Base64
Standard Base64's '+' and '/' characters have special meaning inside URLs and file paths, so a URL-safe variant swaps them for '-' and '_' respectively and often drops the '=' padding. If you paste a JWT or a Base64 string copied from a URL parameter into a tool that only handles the standard alphabet, decoding will fail or silently corrupt the last few bytes — worth checking which flavor you're dealing with before assuming it's broken.
Frequently asked questions
Is my data uploaded?
No — encoding and decoding happen on your device.
Does it support Unicode?
Yes — UTF-8 text is handled correctly.
Does it support Unicode text correctly?
Yes — the encoder converts text to UTF-8 bytes before Base64-encoding, so emoji, accented letters, and non-Latin scripts round-trip correctly rather than getting mangled.
Why is the encoded output longer than my original text?
Base64 trades size for compatibility: every 3 bytes of input becomes 4 characters of output, an overhead of about 33%, plus occasional padding characters.
Is Base64 a form of encryption?
No — it provides zero confidentiality. Anyone can decode it instantly with any standard tool, so never use Base64 alone to 'hide' passwords, tokens, or sensitive data.
Why does decoding sometimes fail with a padding or 'invalid character' error?
This usually means the string was truncated, has whitespace or line breaks mixed in, or is actually URL-safe Base64 (using '-' and '_') rather than the standard alphabet.
Can I decode Base64 back into an actual image or file?
This tool decodes to readable text; for binary output like images you'd typically decode into a data URI or use a dedicated file-conversion tool, since raw binary bytes aren't meaningfully displayable as text.
Is there a limit to how much text I can encode or decode?
Very large inputs (many megabytes) may slow down the browser tab since encoding happens in memory client-side, but typical strings, tokens, and small files process instantly.
Advertisement