Base64 Encode
& Decode
Encode plain text to Base64 or decode Base64 strings back to readable text. All processing happens in your browser.
Master Base64 Encoding & Decoding
How Base64 works, its common uses in web development, and important security considerations.
What Is Base64 Encoding?
Base64 encodes binary data using 64 ASCII characters (A-Z, a-z, 0-9, +, /). It is widely used in email (MIME), data URLs, JWT tokens, and APIs to safely transmit binary data in text-only systems. Important: Base64 is encoding, NOT encryption — it provides no security on its own.
How Base64 Works
3 bytes (24 bits) of binary data are split into four 6-bit groups, each mapped to one of 64 ASCII characters. This means Base64-encoded data is ~33% larger than the original (3 bytes → 4 characters).
Base64 vs Base64URL
Standard Base64 uses + and /, which are problematic in URLs. Base64URL replaces + with - and / with _, used in JWTs and OAuth 2.0. This tool supports both standard and URL-safe Base64 encoding.
Base64 Encoding Examples
Original: Hello
Base64
SGVsbG8=Original: Hello World
Base64
SGVsbG8gV29ybGQ=Original: Base64 Test
Base64
QmFzZTY0IFRlc3Q=Original: {"user":"admin"}
Base64
eyJ1c2VyIjoiYWRtaW4ifQ==Real-World Use Cases
Base64 is ubiquitous in web development: image Data URLs in CSS/HTML, JWT payload encoding, SMTP email attachments, HTTP Basic Auth headers, and embedding fonts in CSS. You encounter it constantly in modern development.
Security Considerations
Base64 is NOT encryption. Do not store passwords or API keys in Base64 thinking it is secure — anyone can decode it instantly. Use proper encryption (AES, RSA) for sensitive data. Base64 is for encoding, not securing.
Performance Impact
Embedding images as Base64 in CSS prevents browser caching and increases file size by 33%. Suitable for tiny icons (under 1KB), but large images should use regular img tag references for better performance.
JWT Tokens
Header and payload Base64URL encoding
Data URLs
Embed images directly in CSS/HTML (data:image/png;base64,...)
MIME Email
Email attachment encoding per RFC 2045
HTTP Auth
Basic Auth header (Authorization: Basic <base64>)
Everything About Base64 Encoding
A deep dive into binary-to-text conversion, data URIs, JWT payloads, and embedding assets in modern web applications.
What is Base64 Encoding?
Base64 is a binary-to-text encoding scheme that represents arbitrary binary data using a restricted alphabet of 64 printable ASCII characters: uppercase letters A through Z, lowercase letters a through z, the digits 0 through 9, and the symbols plus and forward slash. An equals sign serves as a trailing padding character. The encoding was first formally specified in RFC 989 in 1987 as part of the Privacy Enhanced Mail standards, and it was later refined in RFC 2045 for the Multipurpose Internet Mail Extensions used by virtually every email client in the world today. The current authoritative specification is RFC 4648, which also defines the URL-safe variant used in JSON Web Tokens and OAuth flows.
The reason Base64 exists is simple: many transmission channels, protocols, and storage formats were designed for text rather than raw bytes. Email headers, JSON payloads, URL query strings, XML attributes, HTTP cookies, and even some older databases either reject non-printable bytes outright or interpret them as control characters. By converting binary data into a stream of printable characters, Base64 lets developers tunnel images, signatures, certificates, encryption keys, compressed archives, and other binary payloads through text-only systems without corruption. This is why the encoding shows up almost everywhere in modern web infrastructure, from PNG icons embedded in stylesheets to access tokens flying between microservices.
It is essential to understand what Base64 is not. Despite the cryptic appearance of an encoded string, Base64 provides zero confidentiality. The transformation is deterministic, reversible, and well documented, so anyone with access to the encoded value can decode it in milliseconds. Treating Base64 as encryption is one of the most common security mistakes in the industry. Use AES, RSA, ChaCha20, or another vetted cryptographic primitive whenever you need to protect sensitive data. Base64 belongs in your encoding toolbox alongside hex and URL escaping, not in your security toolbox alongside hashing and ciphers.
How Base64 Actually Works
Group bytes into 24-bit blocks
The encoder reads the input three bytes at a time. Because each byte is eight bits, three bytes form a 24-bit chunk. This chunk size is deliberate: it is the smallest number divisible by both eight and six, which lets the algorithm cleanly bridge byte-oriented input and the six-bit alphabet used by Base64.
Split into six-bit sextets
Each 24-bit block is sliced into four groups of six bits. Six bits can represent values from 0 to 63, which maps neatly to the 64 characters of the Base64 alphabet. This is the moment that gives the encoding its name and explains why the output is roughly 33 percent larger than the input.
Map to the alphabet
Each six-bit value is looked up in the standard alphabet table: 0 through 25 become A to Z, 26 through 51 become a to z, 52 through 61 become 0 to 9, 62 becomes plus, and 63 becomes forward slash. The four resulting characters replace the original three input bytes in the output stream.
Pad incomplete groups
When the input length is not a multiple of three, the encoder pads the final group with zero bits and appends one or two equals signs to mark the padding. Decoders recognize the equals signs and discard the corresponding low-order bits, ensuring the round trip recovers the original bytes exactly.
Handle the URL-safe variant
JWT and OAuth specifications avoid plus and forward slash because both characters carry special meaning in URLs. Base64URL substitutes hyphen for plus and underscore for forward slash, and it often omits padding altogether. This tool can switch between standard and URL-safe alphabets without changing the underlying algorithm.
Decode by reversing the steps
A decoder reads four characters at a time, looks up each one in the alphabet to recover six bits, concatenates the bits into 24-bit blocks, and writes three bytes of output. Padding markers are stripped, and the final partial block is shortened accordingly. The result is a byte-for-byte reconstruction of the original input.
Real-World Use Cases
Data URIs for inline images
Web developers regularly embed small icons, SVG logos, and decorative graphics directly in CSS or HTML using data URIs of the form data:image/png;base64,iVBORw0K... This approach eliminates a separate HTTP request, which can dramatically improve perceived performance for above-the-fold rendering. The technique is best reserved for assets smaller than roughly one kilobyte, since the 33 percent size penalty and the loss of browser caching outweigh the savings for larger files. Critical inline SVG sprites and email signature logos are classic candidates.
JWT authentication tokens
Every JSON Web Token consists of three Base64URL-encoded segments separated by dots: the header describing the algorithm, the payload containing claims about the user and token, and the cryptographic signature. The encoding is what lets these tokens ride safely inside Authorization headers, URL query parameters, and cookies without breaking on reserved characters. Decoding a JWT during debugging is one of the most frequent reasons developers reach for a Base64 tool, and the payload becomes human-readable JSON within seconds.
Email attachments via MIME
The Simple Mail Transfer Protocol was designed in an era when only seven-bit ASCII could be reliably transmitted between mail servers. MIME extended SMTP to carry images, PDFs, spreadsheets, and any other binary attachment by Base64-encoding the file contents and adding headers that describe the original media type. Every modern email client transparently encodes outbound attachments and decodes inbound ones, which is why an Outlook user can send a Word document to a Gmail user without thinking about character sets.
HTTP Basic Authentication
The oldest HTTP authentication scheme combines the username and password with a colon, Base64 encodes the result, and places it in an Authorization: Basic header. Because the encoding is trivially reversible, Basic Auth is only safe when paired with TLS, but the format remains common for internal APIs, build pipelines, and webhook callbacks. Knowing how to decode a Basic Auth header by hand is an indispensable debugging skill when an API is rejecting your credentials and the error message is unhelpful.
Embedding fonts and binary assets
CSS @font-face rules can include the actual font file as a Base64 data URL, eliminating an extra network request and the brief flash of unstyled text that comes with it. The same trick works for small audio clips, lottie animations, and even tiny WebAssembly modules. Trade-offs matter: any cached separate file would be reused across pages, while an inline asset must be redownloaded every time the wrapping stylesheet or document changes, so this pattern fits brand-critical assets that load on every page.
Cryptographic keys and certificates
PEM-encoded private keys, X.509 certificates, and OpenSSH public keys all use Base64 internally. The familiar BEGIN PRIVATE KEY and END PRIVATE KEY banners wrap a Base64 representation of the underlying DER bytes, line-wrapped at 64 characters for readability. Configuration management systems, container secret stores, and CI/CD variables typically expect this format because text-only key material is easier to template, diff, and pass between systems than raw binary blobs.
Standard Base64 vs Base64URL: A Practical Comparison
The original Base64 alphabet was a perfectly reasonable choice in 1987, but the rise of the web exposed two awkward characters in the table. The plus sign is reserved in URL query strings as a shorthand for a space, and the forward slash is the path separator. Embedding a standard Base64 string in a URL therefore risks silent corruption: a token containing a plus sign might arrive at the server with the plus replaced by a space, and a string containing forward slashes will break naive routing logic. The padding equals sign is also reserved as the query-string assignment operator, which is why Base64URL drops it entirely whenever possible.
Base64URL solves these problems with a tiny but consequential adjustment. It maps value 62 to the hyphen character and value 63 to the underscore, both of which are unreserved everywhere a URL might appear. Encoders and decoders that respect the specification typically allow padding to be omitted, and the receiving party recomputes the implicit length from the input. This variant is what JSON Web Tokens, OpenID Connect, OAuth 2.0, and modern web push protocols all rely on. If you have ever copy-pasted a JWT from a debugger and pasted it into a tool that returned a parse error, the most common explanation is that the tool expected standard Base64 with padding and was given the URL-safe variant without padding.
A subtler distinction lies in the handling of whitespace and line breaks. The MIME variant defined in RFC 2045 mandates that encoded output be wrapped at 76 characters per line with CRLF separators, which is essential for SMTP compatibility but breaks parsers that expect a single uninterrupted string. The PEM format used by OpenSSL wraps at 64 characters. Many JSON-based APIs deliver Base64 as a single line with no wrapping at all. Robust decoders strip whitespace before processing, but if you write your own implementation, remember to handle every variant your data might travel through. This tool tolerates whitespace automatically so you can paste in PEM blocks, JWT segments, and MIME attachments interchangeably.
Performance is another dimension worth considering. Modern CPUs include SIMD instructions that can encode or decode Base64 at gigabytes per second, and every major language ships a hand-tuned implementation in its standard library. In Python, the base64 module exposes b64encode, b64decode, urlsafe_b64encode, and urlsafe_b64decode. In JavaScript, the browser-native atob and btoa functions handle the standard alphabet, while Buffer.from(str, base64url) in Node.js eighteen and later handles the URL-safe variant. Go provides encoding/base64 with both standard and URL encodings exposed as singleton variables. Knowing the right primitive for your language saves you from rolling a slow handwritten loop.
Pro Tips for Best Results
- Strip line breaks and surrounding whitespace before decoding strings copied from log files, certificate banners, or email source views. Many decoders are strict about extraneous characters and will silently truncate the output at the first unexpected byte, leaving you to chase a phantom data corruption bug that is really a copy-paste artifact rather than a flaw in the producer.
- When debugging JWTs, decode only the header and payload segments and leave the signature alone. The signature is a raw cryptographic value that will look like garbled binary in any human-readable view, while the header and payload contain readable JSON that immediately reveals algorithm choices, issuer claims, audience restrictions, and expiration timestamps. Use a tool that knows the JWT structure if you can.
- For Data URIs in production CSS, run the encoded asset through a build-time optimizer such as svgo or pngquant before embedding. Inlined bytes inherit none of the runtime compression that gzip or brotli applies to your stylesheet, so every saved kilobyte at the source compounds. Reserve inlining for assets smaller than roughly one kilobyte; beyond that, a regular external file with a long cache header almost always wins.
- If you frequently work with binary file content, prefer a tool that supports drag-and-drop file uploads over copy-paste. Browsers can read local files entirely on the client side with the File API, so your bytes never leave the machine. Pasting megabytes of Base64 into a textarea is slow, prone to truncation, and easy to mishandle. A file-aware encoder also preserves binary integrity for edge cases like UTF-8 BOMs and embedded null bytes.
- Never store passwords, API keys, or session tokens in Base64 hoping that the unfamiliar appearance will deter casual snooping. Encoding is not encryption. If a configuration file or log entry needs to contain a secret in any form, encrypt it with a real algorithm and a key managed by your platform secret store. Treat Base64 strictly as a transport-layer convenience for moving binary bytes through text-only channels.
Common Mistakes to Avoid
Confusing encoding with encryption
The single most damaging misconception is the assumption that Base64 protects data. Because the output looks unfamiliar and contains no recognizable English words, many developers, especially those early in their careers, treat encoded strings as if they were confidential. Anyone with a browser and ten seconds can reverse the operation. Use Base64 to move binary bytes through text channels, and use proper cryptography to keep secrets. Combining the two by encrypting first and then encoding the ciphertext is fine; reaching for Base64 alone is not.
Mixing standard and URL-safe variants
A subtle category of bug occurs when one component of a system encodes with the standard alphabet while another decodes with the URL-safe variant. The decoder sees an unexpected plus sign or forward slash, raises an exception, and your authentication or webhook flow breaks. The fix is to pick one variant per protocol boundary and enforce it in code. JWTs, OAuth, and web push always use Base64URL. Email, PEM certificates, and Basic Auth always use the standard alphabet. Mixing them across these boundaries is a recipe for intermittent failures.
Forgetting to URL-encode standard Base64 in query strings
If you absolutely must place standard Base64 inside a URL because the receiving server cannot accept the URL-safe variant, remember that the plus sign, forward slash, and equals sign all require percent-encoding. Failing to percent-encode silently corrupts the value as it passes through routers, proxies, and frameworks that try to be helpful. The cleanest approach is to switch to Base64URL whenever the value will travel inside a URL, and to reserve standard Base64 for HTTP headers, request bodies, and storage.
Treating Base64 as a checksum
Base64 is a lossless reversible encoding, not a fingerprint. Two different inputs always produce two different outputs, but the function does nothing to detect transmission errors or verify integrity. If you need to confirm that a file arrived unmodified, compute a real hash such as SHA-256 and compare hashes on both sides. If you need to authenticate a message, use HMAC or a digital signature. Relying on the encoded string itself as a tamper indicator gives no protection against an attacker who can modify both the data and its encoding.
Inlining large assets as Data URIs
Embedding a hero image or full-page background as a Data URI feels clever but usually backfires. The encoded asset adds 33 percent to its original size, it cannot be cached separately from the wrapping document, and it blocks the parser until the entire blob downloads. The browser cannot render anything that depends on the surrounding HTML or CSS until the inline payload finishes streaming. Reserve the technique for assets smaller than a kilobyte and for cases where eliminating a single HTTP request is provably more valuable than the cache miss it creates.
Beyond Base64: When to Reach for Other Encodings
Base64 occupies a sweet spot between compactness and compatibility, but it is not always the right tool. Hexadecimal encoding doubles the input size rather than inflating it by a third, which seems strictly worse, until you remember that hex is trivially readable by humans and trivially generated in shell scripts. For values that a developer will inspect with the naked eye, such as cryptographic digests, debugging dumps, or short identifiers, hex often wins on ergonomics. The output of sha256sum, the contents of an Ethereum transaction hash, and the bytes printed by hexdump all use hex precisely because the audience is a person, not a parser.
At the other end of the spectrum sit denser encodings designed for size-sensitive contexts. Base85, also known as ASCII85, packs four bytes into five characters using a 85-character alphabet, achieving roughly 25 percent overhead instead of 33. Adobe PDF and the Git binary patch format both use Base85 internally to keep object sizes down. Base91 and Base122 push the trade-off further by using larger alphabets, sometimes including characters that are technically printable but awkward to type or display. These encodings rarely justify the additional complexity outside narrow specialist domains, but they exist when the size savings genuinely matter.
A different family of encodings prioritizes human readability over compactness. Base32 uses only 32 unambiguous characters, deliberately omitting visually confusing pairs like the digit 1 and the letter lowercase L, or the digit 0 and the letter uppercase O. The encoding produces output 60 percent larger than the input, which sounds wasteful, but the result is a string that can be transcribed by phone, read aloud, or typed into a mobile keypad without errors. Time-based one-time password secrets, Tor onion addresses, and many recovery codes use Base32 for exactly this reason. Crockford Base32 takes the readability argument further by also accepting common transcription errors during decoding.
For URL parameters specifically, percent encoding is often the right answer rather than Base64. Percent encoding leaves alphanumeric characters and a small set of safe punctuation untouched, only escaping the bytes that would confuse a URL parser. The result is human-readable for English-language inputs and minimally inflated for ASCII data, while still tolerating arbitrary binary bytes through the percent-XX escape syntax. Use Base64URL for opaque tokens that should not be parsed by intermediaries, and use percent encoding for human-readable values that happen to contain reserved characters.
Key Takeaways
- Base64 is a binary-to-text encoding, not a form of encryption. Anyone can decode an encoded value instantly, so reach for AES, RSA, or another vetted cipher whenever you need actual confidentiality, and treat Base64 strictly as a transport-layer convenience.
- The standard alphabet uses plus and forward slash, which collide with URL syntax. Base64URL substitutes hyphen and underscore so that JWTs, OAuth tokens, and other URL-bound values survive routing intact without manual percent-encoding gymnastics.
- Encoded output is roughly 33 percent larger than the original input because every three bytes of binary data become four characters in the output stream. Plan storage and bandwidth budgets accordingly, especially when embedding assets in stylesheets or HTML.
- Decoders should strip whitespace before processing because real-world Base64 arrives wrapped at 64 characters in PEM, at 76 characters in MIME, and on a single line in modern JSON APIs. A tolerant parser saves hours of fruitless debugging when copy-pasting between contexts.
- Inlining tiny assets as Data URIs eliminates an HTTP request, but the 33 percent size penalty, the loss of separate caching, and the parser-blocking download cost mean the technique only pays off for assets smaller than roughly one kilobyte.
- When in doubt about which encoding to use, match the convention of the surrounding ecosystem: standard Base64 for email and PEM, Base64URL for tokens, hex for human-readable digests, and percent-encoding for plain URL parameters. Consistency at protocol boundaries prevents subtle interoperability failures.
Frequently Asked Questions
What is Base64?
Base64 is an encoding scheme that represents binary data using 64 ASCII characters (A-Z, a-z, 0-9, +, /). It is used to safely transmit binary data like images or files through systems that only handle text.
What is the difference between encode and decode?
Encoding converts your original text or data into a Base64 string, while decoding converts that Base64 string back to the original data. This tool lets you switch between both operations with a single button.
Is Base64 encryption?
No, Base64 is not encryption. Anyone can decode it instantly, so it cannot protect sensitive information like passwords or API keys. Use proper encryption such as AES or RSA for sensitive data.
Is my data uploaded to a server?
No. Encoding and decoding run entirely in your browser. The text or data you enter is never uploaded to any server, so even confidential information is handled securely.
Can I use it for data URIs?
Yes. Base64 is used to build data URIs (the data:image/png;base64,... format) that embed images directly in CSS or HTML. It works well for tiny icons under 1KB, but large images should use regular img tag references.