Encode text to Base64, take an MD5 digest and re-indent JSON. All three run in this page, with notes on what each one is and is not safe for.
For the quick checks that interrupt other work: pasting a credential into a header, comparing a file against a published checksum, or making a wall of minified JSON readable. Everything is computed by JavaScript in your browser, so nothing you paste is uploaded and nothing is kept after you close the tab.
Encodes text as UTF-8 bytes, then represents those bytes with the
64 characters A–Z a–z 0–9 + / and =
padding — the standard alphabet, not the URL-safe variant.
Takes the UTF-8 bytes of your text and returns the 128-bit MD5 digest as 32 lowercase hexadecimal characters. Useful for comparing two things that should be identical.
Parses strict JSON and prints it back with four-space indentation, one value per line. Good for reading a minified API response.
Base64 solves one problem: moving arbitrary bytes through a channel
that only reliably carries printable text — an HTTP header, a
data: URL, an email attachment, a YAML field. It takes
three bytes at a time and writes them as four characters from a
64-character alphabet, padding the last group with = so
the length is always a multiple of four.
That three-to-four ratio is the cost: the result is about
33% larger than the input, plus up to two padding
characters. Inlining a 300 KB image as a data: URL puts
roughly 400 KB into your HTML or CSS, and it cannot be cached
separately.
| Input | UTF-8 bytes | Output |
|---|---|---|
Hello, World! | 13 | SGVsbG8sIFdvcmxkIQ== |
café | 5 | Y2Fmw6k= |
مرحبا 🌍 | 15 | 2YXYsdit2KjYpyDwn4yN |
The third row is the one worth checking. Those are seven characters of
text but fifteen UTF-8 bytes, because the Arabic letters take two bytes
each and the emoji takes four; fifteen divides by three exactly, so the
output is twenty characters with no padding. A tool that encodes
character codes rather than UTF-8 bytes either errors on this input or
returns something else. This one encodes the bytes, so it matches
base64 on the command line.
+, / and = all need
escaping. That is what base64url (with - and
_) exists for, and this tool does not produce it.
MD5 is thoroughly broken as a security primitive, and has been for about two decades. The break is collision resistance: it is practical to construct two different inputs with the same digest. The first real collisions were published in 2004, and the attack became cheap enough that in 2008 researchers used a chosen-prefix MD5 collision to obtain a certificate that browsers accepted as a certificate authority. RFC 6151, Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms, records the conclusion: MD5 must not be used where collision resistance is required.
So, concretely — never use MD5 for:
It is still reasonable where nobody is choosing the input to attack you: spotting an accidentally corrupted or truncated file, finding duplicate files in a folder, building a cache key or an ETag, or checking whether a record changed since the last sync. In those cases you are protecting against bit rot and copy errors, not an adversary, and MD5's speed is a feature. Where you have the choice, SHA-256 costs little more and spares you the conversation.
| Input | Digest |
|---|---|
abc | 900150983cd24fb0d6963f7d28e17f72 |
hello | 5d41402abc4b2a76b9719d911017c592 |
| empty input | d41d8cd98f00b204e9800998ecf8427e |
The digest of nothing at all is a useful thing to recognise: see
d41d8cd9… in a report and you are looking at an empty
file or an empty field, not a hash that failed.
md5("abc") is 900150983cd24fb0d6963f7d28e17f72,
while echo abc | md5sum hashes abc\n and gives
0bee89b07a248e27c83fc3d5951213c1. Use
printf or echo -n to compare like with like.
The formatter parses your text and prints the parsed value back with four-space indentation. It does not edit the text you gave it, which means the output is a faithful rendering of the parsed value and not of your input. Several things differ as a result.
Only strict JSON parses. Trailing commas, single-quoted strings,
unquoted keys, comments, NaN and undefined
are all rejected. When parsing fails you get a browser alert reading
Invalid JSON! and the output box is left exactly as it
was — so a stale result from a previous run stays on screen. There is
no line number and no caret: the alert tells you that something is
wrong, not where. For a long document, paste it into your editor or run
it through a linter to find the position.
Every JSON number is parsed into a 64-bit floating point value, which holds integers exactly only up to 9,007,199,254,740,991. Past that, digits are quietly lost:
| You paste | You get back |
|---|---|
9007199254740993 | 9007199254740992 |
12345678901234567890 | 12345678901234567000 |
1e400 | null |
1.0, 1e2, 0.10 | 1, 100, 0.1 |
The third row is the dangerous one: a value too large for a double
parses as infinity, and infinity is not representable in JSON, so it is
written out as null. No warning is shown. Never paste
account numbers, 64-bit database ids, order references or financial
amounts through a JSON formatter and then save the output — if your
system emits large integers, keep them as JSON strings. This is a
property of JSON parsing in general, not a bug in this page, and most
browser-based formatters behave the same way.
{"a":1,"a":2} becomes a single "a": 2.
é comes back as the literal
character é, while a newline inside a string stays
\n.
42 or
"hi" returns it unchanged. Indentation is fixed at four
spaces: there is no minify, no sort, no tab option and no tree view.
No, it only encodes. Decoding is the direction where malformed input and the two different alphabets cause trouble, and this page does not handle it.
Almost always the text encoding. A tool that encodes UTF-16 code
units, or that drops to Latin-1, gives a different result for any
non-ASCII input. Compare the fifteen-byte example above: if a tool
does not return 2YXYsdit2KjYpyDwn4yN, it is not encoding
UTF-8 bytes.
Not by computation — it discards information, so there is no inverse. But short and common inputs are easy to recover by looking the digest up in a precomputed table, which is why an unsalted digest of a password is effectively the password.
No. All three tools are plain JavaScript running in the page: the MD5 implementation is bundled with the page rather than called over a network, and no request is made when you press a button. The site's own hosting, analytics and advertising are described in the privacy policy.
There is no explicit limit, but everything is held in memory and
processed on the main thread, so a very large paste will freeze the
tab while it works. For files rather than snippets, use
base64, md5sum or jq.