Base64, URL & Hash Tool
Encode or decode Base64, URL, and HTML entities, and generate MD5/SHA hashes — all locally in your browser, nothing sent anywhere.
By Alex van den Berg · Last reviewed · How we test our tools
What each mode is for
Base64
Embedding binary data (images, files) as text in JSON, data URLs, or Basic Auth headers.
URL encoding
Safely putting spaces, symbols, and unicode text inside a query string or URL path.
HTML entities
Displaying raw <, &, and quotes safely inside HTML markup.
Hashing
Verifying file integrity, generating cache keys, or comparing two pieces of text for equality without storing them.
Nothing leaves your browser
Base64, URL, and HTML conversions are pure JavaScript string operations. Hashes are computed with the browser's built-in Web Crypto API for SHA-1/256/384/512, and a local JavaScript implementation for MD5 (which Web Crypto doesn't expose). None of it touches a network request — which matters if you're hashing or encoding something sensitive like an API key, token, or password reset link.
Worked examples
Paste any of these into the tool and you should get the same output. They double as sanity checks when you are debugging an integration and need to know whether the other side encoded a value the way you expected.
| Mode | Input | Output |
|---|---|---|
| Base64 encode | Hello, World! | SGVsbG8sIFdvcmxkIQ== |
| URL encode | price & tax = 20% | price%20%26%20tax%20%3D%2020%25 |
| HTML entities | <a href="x"> | <a href="x"> |
| MD5 | hello | 5d41402abc4b2a76b9719d911017c592 |
| SHA-256 | hello | 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 |
Hashes are case-sensitive and whitespace-sensitive: "hello" and "Hello" produce completely different digests, and a trailing newline changes the result too.
Why Base64 output is a third longer than the input
Base64 takes every 3 bytes of input (24 bits) and writes them as 4 characters of 6 bits each, so the output is always 4/3 the size of the input, rounded up to a multiple of 4. If the input length is not a multiple of 3, the last group is padded with one or two = signs. That is why "Hello, World!" (13 bytes) becomes 20 characters ending in ==. The overhead is the price of being safe to embed anywhere text is allowed; if size matters, compress before encoding, or send the raw bytes with a proper binary content type instead.
This tool encodes text as UTF-8 before converting to Base64, so accented characters, non-Latin scripts and emoji round-trip correctly. Some older tools call the browser's raw btoa() directly, which throws on anything outside Latin-1; and if another system produced Base64 from a different byte encoding (UTF-16, for example), the decoded text will look wrong here even though the Base64 itself is valid.
Encoding a whole URL vs. a single parameter
The URL tab uses encodeURIComponent, which escapes everything except letters, digits and - _ . ! ~ * ' ( ). That is the right choice for a single query-string value or path segment, because it also escapes /, ?, & and =, the characters that would otherwise be read as URL structure. It is the wrong choice for a complete URL: encoding https://example.com/a?b=c as one component turns the slashes and the question mark into %2F and %3F and breaks the link. Encode each value separately, then assemble the URL.
Two other details trip people up. A space becomes %20 here, but HTML forms submitted as application/x-www-form-urlencoded send it as +, so a literal plus sign in form data must be encoded as %2B. And encoding twice is a common bug: %20 encoded again becomes %2520, which decodes back to the literal text "%20" rather than a space.
Which hash should I use?
- MD5 (128-bit): collisions can be produced deliberately, so it must not be used for anything security-related. It is still common for non-adversarial checksums, cache keys and matching against legacy databases that already store MD5 values.
- SHA-1 (160-bit): a practical collision was demonstrated in 2017 and browsers and certificate authorities have retired it. Use it only when an existing system requires it, such as Git object IDs.
- SHA-256 (256-bit): the current default for file integrity, digital signatures, certificate fingerprints and content-addressed storage. If you are not sure which to pick, pick this one.
- SHA-384 and SHA-512: longer digests from the same family. SHA-512 is often faster than SHA-256 on 64-bit CPUs, which makes it a sensible choice for hashing large files locally.
None of these are suitable for storing passwords, whatever the digest length. They are designed to be fast, and fast is exactly what an attacker wants when guessing billions of candidates. Password storage needs a deliberately slow, salted algorithm such as bcrypt, scrypt or Argon2.
Frequently Asked Questions
Is my text sent anywhere?
No. Every encoding, decoding, and hash calculation happens locally in your browser using JavaScript and the Web Crypto API. Nothing is transmitted to a server, which makes this safe for API keys, tokens, and other sensitive strings.
What is Base64 actually for?
Base64 turns arbitrary binary data into plain ASCII text using 64 printable characters, so it can safely travel through systems that only handle text — email attachments, JSON payloads, data URLs, and HTTP Basic Auth headers. It is an encoding, not encryption, and offers no confidentiality.
Why does decoding my Base64 text fail?
Valid Base64 only contains letters, digits, +, /, and = padding. If the text was copied with line breaks, URL-safe substitutions (- and _ instead of + and /), or simply isn't Base64, decoding will fail. Strip whitespace and check for URL-safe variants first.
Should I use MD5 for passwords?
No. MD5 and even SHA-256 are fast general-purpose hash functions, not password hashes — they can be brute-forced or looked up in rainbow tables far too quickly. Passwords should use a dedicated slow algorithm like bcrypt, scrypt, or Argon2. This tool is for checksums, cache keys, and data integrity checks, not credential storage.
What's the difference between URL encoding and Base64?
URL encoding (percent-encoding) escapes characters that aren't safe in a URL, like spaces and &, using %XX sequences — the text stays mostly readable. Base64 re-encodes the entire input into a different, denser alphabet and is used for embedding binary or arbitrary data, not specifically for URLs.
Does Base64 work with emoji and non-English text?
Yes. The text is converted to UTF-8 bytes first and those bytes are Base64-encoded, so any Unicode text round-trips. If Base64 from another tool decodes to garbled characters here, that tool most likely used a different byte encoding before encoding.
Why is the Base64 output longer than my input?
Base64 represents every 3 bytes as 4 characters, so the output is about 33% larger, plus up to two = padding characters at the end. That overhead is inherent to the format, not a bug.
What's the difference between SHA-256 and SHA-512?
Both belong to the SHA-2 family and are considered secure. SHA-256 produces a 64-character hex digest and SHA-512 a 128-character one. SHA-512 works on 64-bit words and is usually faster on modern desktop CPUs, while SHA-256 is more widely expected by APIs, certificates and package managers. Pick whichever the system you are talking to expects; if you have a free choice, SHA-256 is the safe default.