Base64 Encoder and Decoder
Encode any text to Base64 or decode a Base64 string back to text. Use the URL-safe variant when you need to embed the result in a URL or filename. Conversion happens locally in your browser.
Encode any text to Base64 or decode a Base64 string back to text. Use the URL-safe variant when you need to embed the result in a URL or filename. Conversion happens locally in your browser.
Base64 is a binary-to-text encoding that represents arbitrary bytes using only 64 printable ASCII characters: A-Z, a-z, 0-9, plus + and / (or - and _ in the URL-safe variant). It is the standard way to embed binary data — images, certificates, encrypted blobs — inside text-only formats like JSON, XML, email or HTTP headers.
Encoding inflates size by exactly 4/3 (33%): every three bytes of input become four output characters. The encoding is fully reversible, so decoding gives back the original bytes byte-for-byte. The URL-safe variant swaps + and / for - and _ to avoid breaking URL encoding rules.
This tool currently handles text only. For files, drag-and-drop into the converter is on the roadmap. As a workaround, paste the file contents (e.g. via xxd or another tool) or use a desktop utility like base64.
Yes. The input is first encoded as UTF-8 bytes, then those bytes are Base64-encoded. Emoji, accents and CJK characters all round-trip correctly through encode + decode.
Standard Base64 uses + and /, both of which are reserved in URLs. The URL-safe variant (RFC 4648 §5) replaces them with - and _, and drops the trailing = padding. Use this variant for URLs, filenames or JWT segments.
Base64 encodes three input bytes into four output characters, so the result is always ~33% larger. That overhead is the price for using a text-safe alphabet. If size matters (large attachments, payload limits), Base64 is the wrong tool — compress the data first with gzip or zstd, or send raw bytes over a binary-capable channel.
No. Base64 is an encoding, not an encryption. Anyone can decode it instantly without a key — there is no secret involved. If you need confidentiality, use a real cipher (AES-GCM, ChaCha20-Poly1305) and only Base64 the resulting ciphertext if you need to embed it in JSON or a URL.
Where Base64 keeps appearing in everyday web work.
JWTs are three Base64URL chunks separated by dots. Paste the middle chunk to decode the claims and check the user, expiry, or scopes.
Authorization: Basic <Base64(user:pass)> — paste the suffix to recover the colon-separated credentials, useful when debugging upstream services.
Encode a tiny PNG or SVG to inline it directly into HTML or CSS, removing one HTTP request at the cost of ~33% extra bytes.
JSON can't carry raw bytes. Base64 the blob, send it as a string, and decode it on the receiving end — common for file uploads in REST APIs.
Get the right variant for the right job.
+ and / are reserved in URLs and unsafe in filenames. The URL-safe variant (- and _, no padding) avoids both problems.
Base64 inflates size by 33%. If size matters, gzip or brotli first, then Base64 — the compression usually beats the encoding overhead.
Base64 is fully reversible without a key. Never use it as a poor man's secret; pair it with a real cipher when confidentiality matters.
JWT and many URL-safe contexts strip the trailing = padding. Most decoders accept input with or without it, so don't reject on length mod 4.