The TextKit Base64 Encoder converts text to Base64 and decodes Base64 back to text. Base64 is a way of representing arbitrary binary data using only 64 printable ASCII characters — the letters A–Z, a–z, digits 0–9, plus + and /(with = used for padding). It's the standard way to ship binary data through channels that were designed for text.
You've seen Base64 everywhere if you've looked: it's how email attachments are encoded (MIME), how small images are embedded directly in HTML and CSS (data URIs), how JWT tokens are structured, and how secrets are sometimes stored in config files. This tool lets you encode and decode it on demand, in your browser, with no server round-trip.
How to use this tool
- Pick a direction. Text → Base64 encodes your input into a Base64 string. Base64 → Text decodes a Base64 string back into readable text.
- Type or paste your input. For encoding, type any text. For decoding, paste a Base64 string (letters, digits, +, /, and trailing =).
- Read the output. Encoded output appears instantly as a continuous Base64 string. Decoded output appears as the original text.
- Copy and use. Click Copy. Base64 strings paste anywhere — they contain only printable ASCII, so they're safe for any text channel.
How it works
Base64 solves a specific problem: how do you send binary data through a system that only handles text? Email was the original use case. Early email servers only understood ASCII text — they'd mangle or drop bytes outside the printable ASCII range (32–126). To send a JPEG, a PDF, or an executable, you needed a way to represent every possible byte value using only safe printable characters.
The Base64 algorithm works like this: take the input bytes and process them in groups of three. Three bytes = 24 bits. Split those 24 bits into four groups of 6 bits each. Each 6-bit value (0–63) is then looked up in a 64-character alphabet: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/. The result is four ASCII characters representing the original three bytes.
If the input isn't a multiple of three bytes, padding is added. A leftover 1-byte group becomes two Base64 characters followed by ==. A leftover 2-byte group becomes three Base64 characters followed by =. The padding tells the decoder exactly how many bytes to expect.
Worked example: Let's encode the word "Hi". The two characters H (ASCII 72 = 01001000) and i(ASCII 105 = 01101001) are 16 bits total: 01001000 01101001. We pad with zero bits to reach 18 bits (the next multiple of 6): 010010 000110 100100. Converting each 6-bit group to decimal: 18, 6, 36. Looking these up in the Base64 alphabet gives S, G, k. Since we had 2 input bytes (not 3), we add one = padding character. The final result is SGk=. Decode it back and you get "Hi" again.
Because each Base64 character represents 6 bits and each original byte is 8 bits, the encoded output is always about 33% larger than the input — 4 Base64 characters for every 3 input bytes. This is the price of safe transport.
Important security caveat: Base64 is encoding, not encryption. Anyone can decode a Base64 string — there's no key, no secret, no protection. Storing passwords, API keys, or tokens as Base64 in a config file gives a false sense of security. Use real encryption (AES for symmetric, RSA for asymmetric) or a proper secrets manager (Vault, AWS Secrets Manager, Doppler) for sensitive data. Base64's only job is to make binary data safe for text channels — nothing more.
Who uses this tool
Embed small images, fonts, or icons directly in HTML/CSS as data URIs to avoid extra HTTP requests.
Understand and debug MIME-encoded attachments, where binary files are Base64-encoded for transport through SMTP.
Encode binary payloads (like image uploads) for JSON-based APIs that don't natively support binary data.
Inspect and verify JWT tokens, which use Base64URL encoding for the header and payload segments.
Decode secrets stored as Base64 in Kubernetes config maps and secrets for inspection or rotation.
Recognize and decode Base64-obfuscated strings in malware, phishing payloads, and obfuscated JavaScript.
Generate Base64-encoded test inputs for systems that accept or expect Base64-encoded data.
Decode the Base64 strings you find in URLs, cookies, and JWTs to understand what's actually being sent.
Examples
Two input bytes become 3 Base64 chars + 1 padding =. The = tells the decoder there were only 2 original bytes.
13 input bytes become 18 Base64 chars + 2 padding =. Output is ~33% larger than input.
Decoding reverses the process — each 4 Base64 chars become 3 bytes (or fewer, with padding).
Tips & best practices
- Base64 output is always ~33% larger than the input. Don't use it for storage when you could store raw bytes — use it only when you need text-safe transport.
- Base64URL (used in JWTs) replaces + with - and / with _ and drops padding, making the output URL-safe. If you're working with JWTs, look for Base64URL specifically.
- When embedding images as data URIs in CSS, keep them under 4 KB — larger embedded assets slow initial page load more than they save in HTTP requests.
- If you see a long string of letters, digits, +, /, and trailing = characters in a config file, it's almost certainly Base64. Decode it to see what's inside.
- For JWT inspection, decode the header and payload segments (the first two dot-separated parts) to see the algorithm and claims without verifying the signature.
- Don't confuse Base64 with encryption. Encoding is reversible by anyone; encryption requires a key. Never store secrets as plain Base64.
Common mistakes to avoid
- Treating Base64 as encryption. It provides zero confidentiality — anyone can decode it. Use real encryption for secrets.
- Forgetting that Base64 inflates data by ~33%. Embedding large images as data URIs bloats HTML/CSS files and slows parsing.
- Confusing Base64 with Base64URL. The standard alphabet uses + and /; the URL-safe variant uses - and _. JWTs use Base64URL, not standard Base64.
- Truncating Base64 strings. If you cut off the trailing padding (=), the decoder may fail or produce wrong output. Always preserve the full string.
- Storing passwords or API keys as Base64 in source control. It's trivially decoded — anyone with repo access has the secret. Use a secrets manager instead.
- Assuming Base64 strings are unique to the content. Different inputs can produce different-length outputs with different padding, but the encoding is deterministic — same input always produces same output.
“Base64 is the duct tape of the internet — it shows up everywhere, holds everything together, and nobody really likes it. Use it when you need to push binary through a text channel. Don't use it as security. Don't use it for storage. And for the love of clean code, don't ship a Base64-encoded password in a config file and call it 'encrypted.'”
Frequently asked questions
▸Is Base64 encryption?
No. Base64 is encoding, not encryption. Anyone with the encoded string can decode it — there's no key. For confidentiality, use real encryption (AES, RSA) or a secrets manager. Base64's only job is making binary data safe for text channels.
▸Why is Base64 output longer than the input?
Because each Base64 character encodes 6 bits, but each character in the output is 8 bits (one byte). The ratio is 4 output bytes for every 3 input bytes, so the output is ~33% larger. This is the price of text-safe transport.
▸What's the difference between Base64 and Base64URL?
Standard Base64 uses + and /, which have special meanings in URLs. Base64URL replaces + with - and / with _, and often drops padding, making it URL-safe. JWTs use Base64URL for their header and payload segments.
▸What are the = characters at the end?
Padding. Since 3 input bytes become 4 Base64 characters, inputs that aren't multiples of 3 bytes need padding. One = means 2 bytes were encoded (3 chars + 1 pad); two == means 1 byte was encoded (2 chars + 2 pads). The padding tells the decoder how many bytes to produce.
▸Can I use Base64 to store passwords securely?
Absolutely not. Base64 is trivially reversible. For password storage, use a slow key-derivation function like bcrypt, scrypt, or Argon2 with a unique salt per password. Base64 provides zero security.
▸Why do JWTs use Base64?
JWTs need to be compact, URL-safe, and easy to inspect without specialized tools. Base64URL encoding of the JSON header and payload meets all three needs. The signature segment is also Base64URL-encoded, but the JWT's security comes from the signature, not the encoding.
▸Can Base64 encoding fail?
Encoding never fails — any byte sequence can be Base64-encoded. Decoding can fail if the input contains characters outside the Base64 alphabet, has incorrect padding, or has a length that isn't a multiple of 4 (after stripping whitespace).
▸Is there a size limit?
The tool handles tens of thousands of characters comfortably. For very large inputs (megabytes), browser performance varies. Note that decoded output is ~75% the size of the Base64 input, so decoding a large string produces a smaller result.
Last reviewed and updated by Muhammad Umair. Have feedback or found an inaccuracy? Let us know.