Encode text to Base64 or decode Base64 back to text, with full Unicode and URL-safe support, right in your browser.
Base64 Encoder and Decoder converts text to and from Base64, the encoding scheme found everywhere from data URLs and email attachments to API tokens and HTTP headers. Switch to Encode to turn any text, including emoji and extended Unicode characters, into a safe Base64 string. Switch to Decode to turn a Base64 string back into readable text. A URL-safe option replaces the + and / characters with - and _ and strips padding so the result embeds directly in URLs and query strings without percent-encoding. Everything runs locally in your browser, so even secrets, credentials and private tokens never leave your device.
Base64 turns up constantly in modern development, often in places you might not immediately recognise. HTTP Basic Auth headers encode credentials as username:password before transmission. Email protocols use Base64 to carry binary attachments safely through text-based mail servers. CSS and HTML data URIs embed small images and SVG icons as Base64 strings to avoid extra HTTP requests. Many REST APIs return binary data — document previews, thumbnails, certificate content — as Base64 fields inside JSON responses. CI/CD systems and Kubernetes secrets store configuration values in Base64 because the format handles special characters without breaking YAML or environment variable parsing.
Reviewed by the ToolBrainy Team · Runs entirely in your browser · Last updated July 2026
Select "Encode to Base64" if you have plain text, JSON, a credential string or any content you want to convert to Base64. Select "Decode from Base64" if you have a Base64 string you want to turn back into readable text. Paste or type your input and the result updates live as you type.
Standard Base64 uses +, / and = characters that have special meaning in URLs and can break query strings or file paths. Tick "URL-safe (Base64URL)" to switch to the - and _ variant with padding stripped — the format used by JWT tokens and OAuth access tokens. If you are decoding a token copied from a URL parameter or HTTP header and getting an error, tick this option and try again.
Click Copy result to grab the output for pasting into code, a terminal command or a config file. Use Download .txt to save it. If decoding shows "Invalid Base64 input", the string contains characters outside the Base64 alphabet. Check for spaces, line breaks or truncation copied from a terminal or log viewer.
Encoding runs locally, your text is never uploaded.
Handles emoji and accents correctly with UTF-8.
Output the Base64URL alphabet for links and tokens.
No signup, no limits and no watermarks, ever.
An Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ= header in a request log is not encrypted. It is Base64. Paste the encoded portion into Decode and you get username:password immediately, which is useful when tracing authentication issues in server logs or Postman captures.
CSS background images and HTML inline assets use the data:image/png;base64,… format. Encode a small SVG or text payload here to build that string, or paste an existing data URI's Base64 portion to verify the content before embedding it.
Many REST APIs return binary data (document previews, thumbnails, certificate content) as Base64 strings inside JSON responses. Decode the field value here to verify it is what you expect before passing it to your application logic.
For OAuth state parameters, signed URL nonces or session identifiers, encode with the URL-safe option to get a compact string that passes through URL parameters without percent-encoding or breaking routing and signature verification.
Kubernetes stores secret values in Base64, not encrypted. When you need to know what is actually stored in a secret (a connection string, an API key or a service account credential), decode the value here without needing kubectl or cluster access.
Paste "Hello" and encode it, then decode the result back. Compare standard Base64 output with URL-safe output to see exactly why the + and / characters get replaced, a practical way to understand the format before implementing it in code.
Encoding is straightforward: type Hello, World! into the encode box and you get SGVsbG8sIFdvcmxkIQ==. Decode that same string and the original text comes straight back — the two trailing = signs are just padding, not part of the message.
Here is the classic HTTP Basic Auth case from the spec: the credentials Aladdin:open sesame encode to QWxhZGRpbjpvcGVuIHNlc2FtZQ==, which is exactly what sits after the word "Basic" in an Authorization header. Paste that value into Decode and you can read the username and password in plain sight — a good reminder that Basic Auth is not private on its own.
And a URL-safe one: the JWT header {"alg":"HS256","typ":"JWT"} becomes eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. Notice there are no +, / or = characters — that is why it drops cleanly into the first segment of a token without any escaping.
Yes. This tool is completely free with no signup, no limits and no watermarks. Encode and decode as much as you need.
Yes. Text is encoded as UTF-8 before being converted to Base64, so emoji, accented letters and any other Unicode characters round-trip correctly. Paste "café 🚀" into Encode and then decode the result and you will get the original text back exactly.
Standard Base64 uses +, / and =, which have special meaning in URLs. URL-safe Base64 (Base64URL) replaces them with -, _ and no padding, so the result embeds directly in URLs and query strings without breaking anything. Use it for JWT tokens, OAuth parameters, signed URLs, and any identifier that will travel inside a URL.
No. Base64 is an encoding scheme, not encryption. It converts binary data into printable ASCII text so it can travel safely through systems that only handle text, but it provides no security whatsoever. Anyone with the encoded string can decode it in seconds. Never use Base64 alone to protect passwords, keys or sensitive information.
Base64 strings contain only the letters A to Z and a to z, the digits 0 to 9, and +, /, = (or -, _ in URL-safe mode). If the string has a space, a line break copied from a terminal, or any other stray character, the decoder will reject it. Copy the raw string carefully, without surrounding whitespace, and try again.
This tool encodes and decodes text. For text-based formats such as SVG markup, JSON, HTML and plain text, it works perfectly because those are already text strings. To encode an actual binary file such as a PNG or PDF, you would need a tool that reads the file as binary first. For inspecting the text portion of a data URI or an API response field, this tool is ideal.
Base64 works in blocks of three bytes. When your input does not divide evenly into threes, the encoder pads the last block with one or two = signs to keep the length a multiple of four. They carry no data — they just mark how many real bytes were in the final block. URL-safe mode usually drops them entirely, which is why JWT segments have no = at the end.
Yes, by roughly a third. Every three bytes of input become four characters of output, so a 300 KB payload becomes about 400 KB once encoded. That overhead is the trade-off for making binary data survive text-only channels like email, JSON and data URIs. It is why you minify or compress before encoding when size matters.
Decode expects just the Base64 portion, so strip the prefix first. In data:image/png;base64,iVBORw0KGgo…, everything before and including the comma is metadata — paste only what comes after base64,. The same applies to an Authorization: Basic header: drop the word "Basic" and the space, then decode the rest.
They solve different problems. Base64 packs binary into a compact printable set of 64 characters. Hex encoding is simpler to read but doubles the size, using two characters per byte. URL (percent) encoding only escapes the specific characters that are unsafe in a URL and leaves the rest untouched. For moving arbitrary binary through text, Base64 is the most space-efficient of the three.
Yes. Base64 is deterministic — the same input always produces the same output, and decoding reverses it exactly. There is no randomness or key involved, which is precisely why it is an encoding and not encryption.
Yes to both. The conversion runs in your browser, so once the page has loaded it keeps working with no connection, and it behaves the same on a phone as on a desktop — handy for decoding a token or header while you are away from your machine.