Encode or decode Base64, Base64URL, URL percent-encoding, HTML entities and hex as you type, with full UTF-8 support.
Nothing you enter is stored - it is converted and returned in the same request.
A token in a log, a query string in a redirect, an email body full of & - encoded text turns up everywhere at work. Paste it here, pick the format, and see the decoded or encoded result as you type.
A JSON Web Token is three Base64URL parts joined by dots: header, payload and signature. Paste the middle part, choose Base64URL and decode, and you see the JSON claims such as the user id and the exp expiry time (a Unix timestamp you can read with the Timestamp Converter). Decoding is not verifying: anyone can read a JWT payload, and only the signature check on the server proves it was not changed.
Base64 with the padding stripped, which some systems do to save space, fails in strict decoders; this tool adds the missing = signs and tells you it did. A + in a URL query string means a space to many servers, so a Base64 value pasted into a link unencoded arrives corrupted; encode it as a URL component or use Base64URL. Text that was encoded twice shows up as %2520 or & and needs decoding twice.
Base64 decoding ignores spaces and line breaks, so a value wrapped over several lines, as in an email, decodes as pasted. Base64URL decoding also accepts + and /, but plain Base64 rejects - and _, so a JWT part needs the Base64URL option. Hex decoding skips spaces, colons, commas, dashes and 0x prefixes, so 48:65:6c:6c:6f and 0x48 0x65 both work. URL decoding turns + into a space, so a literal plus sign must arrive as %2B. HTML encoding escapes the five characters & < > " and '; HTML decoding understands every HTML5 named entity, such as and …, and numeric ones such as ₹ for the rupee sign.
URL encoding here encodes one value, such as a single query parameter, so every reserved character is escaped: https://example.com/a b?x=1&y=2 becomes https%3A%2F%2Fexample.com%2Fa%20b%3Fx%3D1%26y%3D2. Encode only the value you insert into a link, never the whole link. Text outside ASCII is encoded as its UTF-8 bytes: café ₹ becomes caf%C3%A9%20%E2%82%B9, and hex shows the same bytes, é as c3 a9 and ₹ as e2 82 b9. Base64 of user:pass is dXNlcjpwYXNz, the value an HTTP Basic Authorization header carries (RFC 7617), which is why anyone who sees that header can read the password.
The bytes were UTF-8 but were read somewhere as Latin-1 or Windows-1252 before they were encoded. Decoding here shows the bytes as they are; the fix belongs in the system that produced them.
Paste text up to 200,000 characters. For binary files such as images, the decoded bytes are shown as hex rather than turned into a download.
No. Base64 only changes how bytes are written so they survive systems that expect plain text. Anyone can decode it; never use it to hide a password or secret.
Base64URL swaps "+" and "/" for "-" and "_" and usually drops the "=" padding, so the result is safe inside URLs and file names. JSON Web Tokens use it.
No. It is converted and returned in the same request and never written to a database or log.
This tool also escapes ! ' ( ) and *, which encodeURIComponent leaves as they are, so it's (50%) off! becomes it%27s%20%2850%25%29%20off%21. Both decode to the same text, and escaping those characters is always safe inside a query value. A space becomes %20, not +; the + form comes from HTML form encoding, and the decoder here reads both.
On Linux or Mac, echo -n 'Hello, World' | base64 gives SGVsbG8sIFdvcmxk, and echo 'SGVsbG8sIFdvcmxk' | base64 --decode turns it back. Leave out -n and echo adds a newline that is encoded too, giving SGVsbG8sIFdvcmxkCg==: the most common reason two tools disagree. In PowerShell, [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes('Hello, World')) encodes and [Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('SGVsbG8sIFdvcmxk')) decodes. This page encodes exactly the characters you paste, as UTF-8, and adds no newline.
Paste only the part after the comma: in data:image/png;base64,iVBORw0KGgo... that is iVBORw0KGgo..., because the data:image/png;base64, prefix is not Base64 and the whole string is rejected. Choose Base64 and Decode. Bytes that are not text are shown as hex rather than drawn as a picture, which is still enough to tell what the file is: a PNG starts 89 50 4e 47, a JPEG ff d8 ff, and a whole .docx, .xlsx or other ZIP-based file 50 4b 03 04. To see the image itself, paste the complete data URI into your browser's address bar. Input is capped at 200,000 characters, about 150,000 bytes of file.
Base64 writes every 3 bytes as 4 characters and pads the last group with = to a multiple of 4 (RFC 4648), so the output is 4/3 of the input bytes, rounded up. Hello, World is 12 bytes and becomes the 16 characters SGVsbG8sIFdvcmxk. The count is in UTF-8 bytes, not letters: café is 4 characters but 5 bytes and becomes Y2Fmw6k=, and ₹100 is 6 bytes and becomes 4oK5MTAw. Email attachments grow a little more because MIME breaks Base64 into lines of at most 76 characters (RFC 2045); this page ignores those line breaks when decoding. Base64URL without padding saves only the = signs.