What the encoder / decoder does
This tool handles the two encodings developers run into most often: URL encoding (percent-encoding), which makes text safe to put in a web address, and Base64, which turns any bytes into plain ASCII text. Paste text, pick a direction, and get the result instantly. Both encodings are reversible and provide no secrecy — they exist to move data through channels that only accept certain characters. Processing happens in your browser.
URL encoding
URLs may only contain a limited set of characters. Anything else — spaces, accented letters, &, =, ?, #, non-Latin scripts — must be written as a percent sign followed by the byte's hex value. The text is first encoded as UTF-8, then each unsafe byte is escaped.
Hello World → Hello%20World
price=5&qty=2 → price%3D5%26qty%3D2
กรุงเทพ → %E0%B8%81%E0%B8%A3%E0%B8%B8%E0%B8%87%E0%B9%80%E0%B8%97%E0%B8%9E
café → caf%C3%A9| Character | Encoded | Why it must be escaped |
|---|---|---|
| space | %20 (or + in form data) | Ends the URL in many parsers |
| & | %26 | Separates query parameters |
| = | %3D | Separates key from value |
| ? | %3F | Starts the query string |
| # | %23 | Starts the fragment — everything after is dropped by the server |
| / | %2F | Path separator |
| % | %25 | Escape character itself |
The tool uses encodeURIComponent semantics, which escapes everything except letters, digits and - _ . ! ~ * ' ( ). That is the right choice for a single parameter value. If you are encoding a whole URL that already has its structure, encode only the parts, not the separators.
Base64
Base64 represents binary data using 64 printable characters (A–Z, a–z, 0–9, +, /) plus = for padding. Every 3 bytes become 4 characters, so output is about a third larger than input. It is how images are embedded in HTML, how email attachments travel, and how binary values are stored in JSON and JWTs.
Hello → SGVsbG8=
{"ok":true} → eyJvayI6dHJ1ZX0=Text is encoded as UTF-8 before conversion, so non-Latin characters round-trip correctly. A variant called Base64URL swaps + and / for - and _ and drops padding; JWTs use it. Standard decoders often accept both.
When you need each one
- URL encode a search term, a redirect URL passed as a parameter, or a filename with spaces before building a link.
- URL decode a query string you copied from a browser or a log to see what was actually sent.
- Base64 encode credentials for an HTTP Basic auth header (
user:password), a small image for a data URL, or a config file to paste into a YAML secret. - Base64 decode a JWT segment, an API response field, or a Kubernetes secret to read its contents.
Neither is encryption
Both encodings are fully reversible by anyone with no key. A Basic auth header, a Base64 secret in a repo, or a token in a URL is exposed in plain sight to whoever sees it. Use TLS to protect data in transit and real encryption (AES, or your platform's secret manager) for data at rest. Encoding is about character sets, not confidentiality.