Base64 encoder
What Is Base64 Encoding?
Base64 is a way of representing binary data — images, files, encryption keys, any byte sequence — as plain ASCII text. It takes every 3 bytes of input (24 bits) and re-splits them into 4 groups of 6 bits, mapping each 6-bit group to one of 64 safe characters: A–Z, a–z, 0–9, plus "+" and "/" (with "=" used as padding when the input length isn't a multiple of 3). The result is text that survives systems designed only for text: email bodies, JSON payloads, URLs, HTML attributes, and source code.
Why does this transformation exist at all? Much of the internet's infrastructure was built for 7-bit ASCII text. Email (SMTP) was originally text-only; binary attachments would be corrupted by mail servers that mangled non-text bytes. The fix, standardized in MIME, was to encode attachments as Base64 text on sending and decode them back to binary on receipt — which is why every email attachment you've ever received traveled as a long block of Base64 inside the message. The same principle applies anywhere binary must ride inside a text channel: embedding an image directly in HTML or CSS via a data URI, stuffing binary into a JSON API field, or passing a token through an HTTP header.
Two facts about Base64 are constantly misunderstood. First, Base64 is not encryption. It provides zero confidentiality — anyone can decode it instantly, with no key. Encoding a password in Base64 does not protect it; it only changes its appearance. Second, Base64 expands data by about 33%: every 3 input bytes become 4 output characters. That overhead is the price of text-safety, and it's why you wouldn't Base64-encode a 500 MB video for fun — but for small payloads like thumbnails, icons, and tokens, the convenience outweighs the cost.
The WebTaskTools Base64 encoder takes any text you paste and returns its Base64 representation instantly, with options for standard and URL-safe alphabets and proper padding handling. Your input is processed instantly on the server and never stored. To reverse the process, use our companion Base64 decoder. Developers working with web data often move between this tool and our URL encoder (for percent-encoding) and JSON formatter (for inspecting API payloads).
How to Use the Base64 Encoder
- Paste or type your text. Enter any text into the input box — plain words, JSON, HTML snippets, configuration values, or credentials you need to transport as text.
- Choose the alphabet. Use standard Base64 (with + and /) for email, data URIs, and general use; use URL-safe Base64 (with - and _ instead) when the output will live inside a URL or filename.
- Click Encode. The tool instantly converts your input to Base64, applying = padding as needed.
- Copy the output. Use the copy button to grab the encoded string and paste it into your email, code, API call, or config file.
- Decode to verify. Paste the output into a Base64 decoder to confirm it round-trips back to your original text exactly.
- Clear and repeat. Clear the boxes and encode the next value — unlimited conversions per session.
How Base64 Actually Works
The algorithm is beautifully simple. Take the ASCII text "Man": its bytes are 01001101 01100001 01101110. Regroup those 24 bits into four 6-bit chunks: 010011 010110 000101 101110. Each chunk is a number from 0–63, which indexes into the Base64 alphabet: 19→T, 22→W, 5→F, 46→u. So "Man" encodes to "TWFu". When the input isn't a multiple of 3 bytes, padding fills the gap: "Ma" (2 bytes) becomes "TWE=" and "M" (1 byte) becomes "TQ==". The "=" signs tell the decoder how many bytes were in the final group.
The URL-safe variant (RFC 4648 §5) swaps "+" → "-" and "/" → "_", because "+" means "space" in URL query strings and "/" separates path segments — both would corrupt standard Base64 inside a URL. JWT tokens use this variant. Some systems also strip the "=" padding in URL-safe mode since it's unnecessary when the length is known, though strict decoders may require it — when in doubt, keep the padding.
| Variant | Characters 62 and 63 | Padding | Common uses |
|---|---|---|---|
| Standard (RFC 4648) | + and / | = (required) | Email MIME, data URIs, XML, general encoding |
| URL-safe (RFC 4648 §5) | - and _ | = (often omitted) | JWTs, URL parameters, filenames |
Key Features
- Instant encoding — paste text and get Base64 output immediately, with no submit step.
- Standard and URL-safe alphabets — pick the right variant for email/data-URIs or for URLs and tokens.
- Correct padding — = padding applied exactly per RFC 4648 so strict decoders accept the output.
- Unicode support — non-ASCII text is UTF-8 encoded before Base64 conversion, matching what browsers and APIs expect.
- One-click copy — grab long encoded strings without manual selection errors.
- Round-trip verification — decode the output to confirm fidelity before using it in production.
- Not stored — input is processed instantly and never stored, logged, or retained.
- Free and unlimited — encode as much as you need at no cost.
Where Base64 Shows Up in Real Life
Email attachments (MIME). Every attachment travels as Base64 inside the message body — open a raw .eml file and you'll see the long encoded blocks between MIME boundaries. This is the original killer app from the early 1990s, and it still carries the world's email attachments daily.
Data URIs in web pages. Small images, fonts, and icons can be embedded directly in HTML or CSS as data:image/png;base64,iVBORw0KGgo…. This eliminates HTTP requests for tiny assets (a classic performance optimization), at the cost of ~33% larger payloads and uncacheable inline data — worth it for a 2 KB icon, wasteful for a 2 MB photo.
HTTP Basic Authentication. The Authorization: Basic header carries base64(username:password). Note the colon separator and the critical fact that this is encoding, not encryption — Basic auth without HTTPS exposes credentials to anyone watching the network, which is why it must always ride over TLS.
JWTs (JSON Web Tokens). A JWT is three Base64url-encoded segments joined by dots: header.payload.signature. The payload is merely encoded, not encrypted — anyone can decode it — so never put secrets in a JWT payload. Signature verification, not obscurity, is what makes JWTs trustworthy.
APIs and JSON payloads. JSON has no binary type, so APIs that must transport files, images, or binary blobs embed them as Base64 strings. AWS APIs, for example, routinely accept Base64-encoded data in JSON fields.
Use Cases
Web developers
The problem: A tiny logo or icon needs to ship with a single-file HTML email or a CSS bundle, and a separate image request (or a broken relative path in production) is unacceptable.
How this tool helps: Encode the asset's bytes as Base64 and inline it as a data URI. For quick text-based experiments — encoding a small SVG or a JSON config — paste the content here and get the encoded string in seconds.
API developers and testers
The problem: An endpoint expects a Base64-encoded file upload inside a JSON body, or a test fixture needs a realistic encoded payload, and hand-crafting one is error-prone.
How this tool helps: Encode sample payloads instantly for Postman collections, integration tests, and seed data. Verify them with the decoder before committing to the test suite.
Email developers
The problem: Debugging a broken attachment or building MIME messages by hand requires understanding exactly what the encoded body should look like.
How this tool helps: Encode and decode snippets to inspect MIME bodies during troubleshooting, confirming that attachment corruption comes from transport issues rather than encoding errors.
DevOps and SRE engineers
The problem: Kubernetes secrets, CI variables, and cloud-init configs frequently require Base64-encoded values, and getting the encoding wrong (trailing newlines, wrong alphabet) causes cryptic deployment failures.
How this tool helps: Produce clean, correctly padded Base64 for secrets and config values, and double-check existing values by decoding them before they go into the cluster.
Students learning networking
The problem: Textbooks describe Base64 abstractly, but the concept clicks only when you watch real text transform and transform back.
How this tool helps: Encode "Hello" and see "SGVsbG8="; decode it back. Experiment with padding by encoding 1-, 2-, and 3-character inputs to watch the "=" signs appear and disappear — the algorithm becomes obvious.
Security learners (with caution)
The problem: Beginners often mistake Base64 for encryption and "protect" secrets by encoding them — a dangerous misunderstanding.
How this tool helps: The instant decode demonstrates the point viscerally: if you can decode it in one click with no key, so can an attacker. Learn the distinction here, where the stakes are zero.
Base64 vs. URL Encoding vs. Hex: Which to Use?
Beginners often reach for the wrong text-safe encoding. The three common choices solve different problems. Base64 converts arbitrary binary into a compact-ish ASCII string (~33% overhead) — best when the payload is binary or large-ish text that must survive a text channel. URL encoding (percent-encoding) leaves safe characters alone and escapes only the problematic ones as %XX — best for short strings inside URLs, where most characters need no transformation at all. Hex encoding renders every byte as two characters (100% overhead) — best when humans need to read or compare the bytes, as with hash digests and cryptographic keys.
| Encoding | Overhead | Output alphabet | Use it when… |
|---|---|---|---|
| Base64 | ~33% | A–Z a–z 0–9 + / = | Embedding binary in email, JSON, HTML, or configs |
| URL encoding | 0% for safe chars | Original text + %XX escapes | Putting user input into query strings and paths |
| Hex | 100% | 0–9 a–f | Displaying hashes, keys, or binary for humans to compare |
A useful rule of thumb: if the data started as text and just needs to survive a URL, use a URL encoder. If it started as binary (or text that must survive email/JSON), use Base64. If you need a human-readable fingerprint of data, compute a hash with our SHA-256 generator and read it in hex. If you need a human-readable fingerprint of data, compute a hash with our SHA-256 generator and read it in hex. Mixing them up — Base64-encoding a URL parameter instead of percent-encoding it, for example — produces output that technically works but confuses every developer who reads it later.
Troubleshooting Base64 Problems
"Incorrect padding" errors. The most common failure. It means the string length isn't a multiple of 4 — usually because padding was stripped, whitespace crept in, or the string was truncated during copy-paste. Re-copy carefully, or programmatically pad with "=" until the length divides evenly by 4.
Mojibake after decoding. If decoded text shows garbled characters (é instead of é), the bytes were interpreted as Latin-1 instead of UTF-8. Make sure both ends agree on UTF-8: encode the original text as UTF-8 bytes before Base64, and decode the result as UTF-8 afterward.
Plus signs turning into spaces. Standard Base64 contains "+", which HTML forms decode as a space. If encoded data passes through a form field or query string, either use the URL-safe alphabet or percent-encode the output first — otherwise decoding produces garbage.
Line breaks in the output. MIME convention wraps Base64 at 76 characters per line. Most modern decoders ignore whitespace, but strict ones reject it. If an API chokes, strip all newlines from the encoded string before sending.
Looks encoded but won't decode. Verify the alphabet: a string with "-" and "_" is URL-safe and needs a URL-safe decoder; feeding it to a standard decoder fails. Also check for confusable characters introduced by rich-text editors — smart quotes and em-dashes are not Base64 characters.
A Note on Performance
For the short strings this tool handles — tokens, snippets, config values — Base64 encoding is effectively instantaneous and the 33% size overhead is irrelevant. It only becomes a design consideration at scale: encoding large files inflates storage and bandwidth bills by a third, and encoding on every request adds CPU cycles to hot paths. High-traffic systems therefore encode once and cache the result, or skip Base64 entirely in favor of direct binary transfer (multipart uploads, binary WebSocket frames, or object-storage URLs). As a rule, use Base64 for convenience with small payloads and switch to binary-native transport when the bytes get big or the traffic gets heavy.
Frequently Asked Questions
Is Base64 encryption?
No — and this is the most important thing to understand. Base64 is an encoding, a change of representation, not an encryption, which requires a secret key. Anyone can decode Base64 instantly. Never use it to "protect" passwords, tokens, or personal data; use real encryption (AES) or hashing (SHA-256, bcrypt) for those purposes.
Why is Base64 output longer than the input?
Because 6 bits are being represented per output character instead of 8 bits per input byte. The math works out to a 4:3 ratio — output is ~33% larger, plus up to 2 padding characters. This overhead is the cost of restricting output to 64 universally safe characters.
What are the = signs at the end?
Padding. Base64 processes input in 3-byte groups; if the final group has only 1 or 2 bytes, "=" characters pad the output to a multiple of 4. One "=" means the last group held 2 bytes; "==" means it held 1 byte. Decoders use this to reconstruct the exact original length.
Standard vs. URL-safe Base64 — which should I use?
Use standard Base64 for email, data URIs, XML, and general storage. Use URL-safe Base64 (with - and _ instead of + and /) whenever the output goes into a URL, query parameter, or filename, where "+" and "/" have special meanings. JWTs always use the URL-safe variant.
Can Base64 encode binary files like images?
Yes — that's its primary purpose. The encoder on this page handles text input; for actual binary files, you'd read the file's bytes and encode them (every programming language has a one-liner for this). The resulting text can then travel through email, JSON, or HTML and be decoded back to the exact original bytes.
Why does my API reject the encoded string?
The usual suspects: wrong alphabet (standard vs. URL-safe), missing or extra padding, stray whitespace or line breaks copied along with the output, or the API expecting the raw bytes of a file while you encoded its text representation. Decode your string and compare byte-for-byte with the source to isolate the issue.
Is Base64 case-sensitive?
Yes — "A" and "a" map to different 6-bit values (0 and 26). Changing the case of even one character corrupts the decoded output. Never "normalize" the case of a Base64 string.
How do I decode Base64?
Use our Base64 decoder — paste the encoded string and get the original text back instantly. In code, every major language has built-ins: atob() in browsers, base64.b64decode() in Python, Buffer.from(s, 'base64') in Node.js.
Does Base64 work with emoji and non-English text?
Yes, when the text is first encoded as UTF-8 bytes (which is what this tool and all modern systems do). The emoji's UTF-8 bytes are Base64-encoded like any other bytes, and decoding reverses the process exactly. Problems only arise with legacy systems that assume Latin-1 instead of UTF-8.
Is my input stored when I encode it?
No. Your text is processed instantly to produce the encoded output and never stored, logged, or retained. That said, as a standing best practice, avoid pasting live production secrets into any website — generate test values here and handle real credentials in your own tooling.