Cookies for analytics and advertising
We use cookies for analytics and advertising, both sent to Google. Refusing changes nothing you can see.Read the privacy page
Hex encode
Paste text and read the bytes it is made of. Two hexadecimal digits per byte, with the separator whatever you are pasting into wants — a space for a hex editor, nothing for a protocol field, a colon for a fingerprint. The bytes are UTF-8, which is the part most implementations get wrong.
Where it runs
Nothing is uploaded, because there is no file — it is worked out in this page.
No queue, no account
It answers as fast as your machine can, and it never asks who you are.
As often as you like
Nothing is counted and nothing is capped — answering again costs us nothing.
How it works
- Paste the text into the box.
- Pick the separator and the case your destination expects.
- Copy the dump. Nothing was uploaded to produce it.
A character is not a byte, and this is where you find out
Every hexadecimal dump is really a question about encoding, and the question is invisible until the text stops being ASCII. In UTF-8 a Latin letter with a diaeresis takes two bytes, a CJK character three and an emoji four; in UTF-16 the same letter takes two bytes and the emoji four, arranged differently; in latin1 the letter takes one and the emoji cannot be represented at all.
This page emits UTF-8, because that is what a file on disk, a request body and a database column overwhelmingly hold today. The classic wrong implementation reads the code unit at each index instead, which gives one byte per character for anything in the Latin-1 range — so `ü` comes out as `fc` where the file holds `c3 bc`, and every test written on English text passes.
Why the separator is a setting rather than a style
Because the destination decides it and the destinations disagree. A hex editor and most documentation want bytes separated by a space. A protocol field, a colour value or an identifier wants an unbroken run. A certificate fingerprint or a MAC address wants colons. An array literal in C or Java wants commas.
None of those is more correct than the others, and converting between them by hand over a long dump is exactly the kind of task that introduces a typo you will spend an hour finding. The decoder on the companion page accepts all four without being told which, so a round trip through this pair is lossless whichever you choose.
Case matters to people, not to parsers
Every hexadecimal parser worth using accepts both, so the choice is about the eye rather than the machine. Lower case is the convention in Unix tooling, in Git object identifiers and in most modern documentation. Upper case is what hex editors, RFCs and a lot of embedded work print, and it is easier to scan when the digits are mixed with letters in a long line.
The one place it is not cosmetic is a comparison done as strings. A checksum compared with `===` against a value in the other case fails while being correct, which is a bug that survives review because both values are visibly the same number. Compare case-insensitively, or normalise before you compare.
What a hex dump is genuinely good for
Finding what is not visible. A trailing newline, a non-breaking space that a word processor inserted, a byte-order mark at the front of a CSV that makes the first column header not match, a doubled space in a key — none of those are visible in a text box and all of them are obvious in a dump.
The byte-order mark is the one worth naming. `ef bb bf` at the start of a file is a UTF-8 BOM, and it is why a column called `id` refuses to match the string `id` in a script that is otherwise correct. Paste the first line of a misbehaving file here and it either is there or is not, which takes a minute rather than an afternoon.
Hex encode: common questions
Which encoding do the bytes represent?
UTF-8. That is what files, request bodies and database columns hold in practice, and it is what the modern web specifies. If you need UTF-16 or latin1 you need a different tool — and it is worth being sure you do, because the usual reason to think so is a system whose declared encoding is wrong rather than one whose encoding really is different.
Why is one character several bytes?
Because UTF-8 is variable width. ASCII takes one byte, most accented Latin and Greek and Cyrillic take two, CJK takes three and emoji take four. A dump that shows one byte per character for accented text is not encoding UTF-8 at all, which is the most common defect in tools of this kind.
Does the separator or the case change the value?
No. Both are presentation, and the decoder on the companion page strips whatever separator it is given — spaces, colons, commas, even a 0x in front of each byte — before reading the digits. Pick whichever your destination expects.
Can I use this to look at a file?
Not directly — this takes text rather than a file. For a file you want a hex editor, or the checksum tool here if what you actually need is a digest. Pasting the first line of a text file in is still useful for finding a byte-order mark or a stray character at the start.
Is what I paste uploaded?
No. The conversion is a few lines of arithmetic running in this page, and the network panel will show nothing carrying your text. The things people dump to hex are often keys and protocol fields, which is precisely the category that should not be travelling.