A complete guide to Base64 and URL percent-encoding, how Base64 actually works mechanically, and why neither scheme provides any real security.
Launch the Base64 URL Encoder/Decoder →The Base64 URL Encoder/Decoder converts text between its plain, readable form and two different common encoding schemes: standard Base64 encoding, and URL-safe percent-encoding (sometimes called URL encoding). A mode toggle lets you choose which encoding scheme to apply, and a direction toggle lets you switch between encoding (plain text to encoded form) and decoding (encoded form back to plain text), with a convenient Swap button to move the current output into the input field for quick back-and-forth testing.
Both encoding schemes exist for different, specific purposes, and understanding when each one is actually the right tool for a given situation is as useful as knowing how to perform the conversion itself.
Base64 encoding converts arbitrary binary data, or any text, into a representation using only 64 printable ASCII characters (A–Z, a–z, 0–9, plus two additional symbols, typically + and /). It exists to solve a specific, narrow problem: many older systems, protocols, and data formats were designed to only reliably handle plain printable text, not arbitrary binary bytes, which could contain characters that confuse those systems (control characters, null bytes, or bytes that look like formatting markers in a particular protocol).
Email attachments are a classic example: raw binary files can't always be safely embedded directly into an email message body, which was historically designed around plain text, so Base64 encoding converts the binary attachment into a safe, all-text representation that any email system can transmit without corruption. Base64 is also commonly used to embed small images or other binary resources directly inside text-based formats like HTML, CSS, or JSON, where a literal binary blob wouldn't fit naturally into the surrounding text structure.
Critically, and this is a point worth being completely unambiguous about: Base64 is not encryption, and provides zero confidentiality or security. It's a reversible, publicly documented, standardized transformation that anyone can decode using any Base64 decoder, including this tool, with no secret key, password, or any other protective barrier required. Encoding sensitive information in Base64 does not protect it in any meaningful sense; it only changes its surface representation into a form that happens to look unreadable to someone glancing at it casually, which is a form of mild obfuscation at best, never genuine security.
URL encoding, formally called percent-encoding, serves a completely different purpose from Base64: it makes arbitrary text safe to include inside a URL or a URL query string, where certain characters have special, reserved meaning (like & separating query parameters, ? starting the query string, / separating path segments, and spaces, which aren't technically allowed in a URL at all). Percent-encoding replaces any character that could be misinterpreted or cause a problem with a percent sign followed by that character's two-digit hexadecimal code, such as encoding a space as %20.
This matters constantly in web development and everyday internet use: if you need to pass a piece of text containing spaces, special characters, or non-English characters as part of a URL (for example, as a search query parameter), that text needs to be percent-encoded first, or the URL could be parsed incorrectly, truncated at an unintended character, or simply rejected by the receiving server as malformed.
A simple rule of thumb: if you're working with binary data, or need to embed arbitrary content inside a text-based format or protocol that doesn't natively support binary (email attachments, embedding small files in JSON or HTML, certain authentication token formats), Base64 is the appropriate choice. If you're constructing or decoding a URL and need to safely include text that contains spaces, special characters, or symbols with reserved meaning in URL syntax, URL/percent-encoding is the appropriate choice.
Using the wrong one for a given situation won't necessarily produce an error, but it won't solve the actual problem either: percent-encoding arbitrary binary data doesn't reliably make it safe for contexts that specifically expect Base64's output alphabet, and Base64-encoding a URL query parameter doesn't make it safe to actually place inside a URL, since Base64's own output alphabet includes characters like + and / that have their own special meaning in URL syntax (which is part of why a URL-safe variant of Base64, replacing those two characters, exists separately in some contexts, though this tool's URL mode specifically refers to percent-encoding rather than URL-safe Base64).
Understanding the actual mechanism behind Base64 clarifies why it behaves the way it does, including why encoded output is always roughly a third longer than the original input. Base64 works by taking the input data three bytes (24 bits) at a time, and re-splitting those 24 bits into four groups of 6 bits each. Each 6-bit group, which can represent a value from 0 to 63, is then mapped to one specific character from the 64-character Base64 alphabet (uppercase letters, lowercase letters, digits, and two symbol characters).
This 3-bytes-in, 4-characters-out ratio is exactly why Base64-encoded output is always about 33% larger than the original input: three bytes of original data become four bytes (characters) of encoded output, every time, regardless of what the original content actually was. When the input's total length isn't an exact multiple of three bytes, padding characters (typically =) are added at the end to indicate exactly how many bytes of "real" data were present in that final group, which is why some Base64 strings end with one or two equals signs and others don't, depending on the original input's exact length.
This mechanical process is also why Base64 cannot provide any security benefit on its own: it's a completely deterministic, publicly known, one-to-one mapping with no secret component anywhere in the process. Given any Base64-encoded string, reversing it back to the original data requires nothing more than knowing the (entirely public, standardized) alphabet mapping, which is precisely why this tool, or any other Base64 decoder, can decode arbitrary Base64 content instantly with no special access or permission needed.
Encoding the text Hello, World! in Base64 mode produces SGVsbG8sIFdvcmxkIQ==, while encoding the same text in URL mode produces Hello%2C%20World%21, demonstrating how differently the two schemes handle the same input based on their different underlying purposes.
All encoding and decoding happens entirely within your browser using standard, built-in JavaScript encoding functions. No network request of any kind is made by this tool, and nothing you type or paste is ever transmitted anywhere, logged, or stored.
No, and this is worth repeating clearly: Base64 is a reversible, publicly standardized encoding, not encryption. Anyone with access to Base64-encoded text can decode it back to its original form with no secret key or password required, using this tool or countless others.
This typically means the input wasn't actually valid, correctly formed data in the encoding mode you selected — for example, trying to Base64-decode text that was actually percent-encoded, or that contains characters outside the Base64 alphabet, will not produce a meaningful result.
Standard Base64's output alphabet includes characters like + and / that have special meaning within URL syntax, so standard Base64 output generally still needs additional URL/percent-encoding before being safely placed directly into a URL, which is a different situation from the URL-safe Base64 variant some systems use specifically to avoid this problem.
Base64 is generally used for embedding or transmitting binary or arbitrary content through text-only channels, while URL encoding is specifically about making text safe to include within a URL's structure. Choosing based on your actual destination or use case, as described in the Choosing the Right Mode section above, avoids confusion between the two.