Paste a packet capture, a serial log line or a hex dump from a debugger. The converter splits the bytes, prints the readable text, names control codes like CR or LF, then flags every byte above 7F, since plain ASCII stops at 127.
| Offset | Hex | Dec | Binary | Char |
|---|
Byte dumps arrive in a dozen shapes. Wireshark copies 48 54 54 50. C source uses 0x48, 0x54. Python prints b'\x48\x54'. URL logs show %48%54. Some firmware tools print one long run such as 48545450. Paste any of these as-is. The parser strips the prefixes, splits on spaces, commas, colons, dashes or line breaks, then cuts long hex runs into pairs.
48 65 6C, 0x48,0x65, \x48\x65, %48%65, 48656C72 101 108, values 0 to 25501001000 01100101, or one unbroken run in multiples of 8 bits110 145 154, values 0 to 377Auto mode guesses from the tokens. Letters A to F or a 0x prefix mean hex. A three digit number means decimal. Groups of eight zeros or ones mean binary. One case stays ambiguous: 48 65 72 is valid hex, reading Her, but also valid decimal, reading 0AH. Auto picks hex here, since hex dumps pad every byte to two digits. The status line under the input says so whenever this happens. Click Decimal if your source prints decimal.
ASCII dates from 1963 as a 7-bit code. A byte holds 8 bits, so half of the 256 byte values carry no ASCII meaning at all. A decoder printing é for byte E9 has assumed Latin-1 without telling you. This page flags those bytes as [E9] by default, so a wrong guess never lands in your clipboard. Pick an encoding under "Bytes above 7F" once you know the source.
| Hex range | Decimal | Output here |
|---|---|---|
00 to 1F | 0 to 31 | Control codes, shown by name: NUL, TAB, LF, CR, ESC |
20 to 7E | 32 to 126 | Printable characters, from the space up to the tilde |
7F | 127 | DEL, also a control code |
80 to FF | 128 to 255 | Not ASCII. Flagged, or decoded as Windows-1252 or UTF-8 on request |
Most of the 33 control codes died with teletypes. These eight still show up in captures, logs or files people paste here.
| Bytes | Name | Where you see them |
|---|---|---|
00 | NUL | End of a C string, padding in fixed-width records, every second byte of UTF-16 English text |
09 | TAB | TSV exports, Makefile recipes |
0A | LF | Line end on Linux or macOS, the separator in NDJSON logs |
0D 0A | CR LF | Line end in HTTP headers, SMTP, Windows text files |
06 / 15 | ACK / NAK | XMODEM transfers, barcode scanners, older serial devices |
1A | SUB | End-of-file marker in DOS text files, also inside the PNG signature |
1B | ESC | Start of terminal color codes. 1B 5B 33 31 6D switches the text to red |
7F | DEL | Sent by the Backspace key on many Linux terminals |
Set Control codes to "Keep as real characters" when you want the copied text to carry real line breaks. Keep the names on while debugging, since a stray CR before an LF looks identical to a clean line end once rendered.
Load the sample. With high bytes flagged, the output reads [89]PNG[CR][LF] on line one, then [SUB][LF] on line two. None of those bytes is decoration. Each one traps a different kind of transfer damage:
89 sits above 7F. A channel which strips the eighth bit turns the byte into 09, so a 7-bit mail gateway breaks the file on byte one.50 4E 47 spell PNG in ASCII. Anyone scanning a raw dump spots the file type by eye.0D 0A is a Windows line ending. An FTP client in text mode collapses the pair into a lone LF, shifting every later byte.1A is SUB. The DOS type command stops printing here, before the binary noise starts.0A is a lone LF. A converter going the other way, LF to CR LF, adds a byte here, so the reverse damage gets caught too.The same reading habit works on any unknown file. Paste the first 16 bytes from a hex editor, look for a readable tag such as %PDF, PK or GIF89a, then check the control codes around the tag.
48 00 65 00 decodes to H[NUL]e[NUL]. Drop the 00 bytes first, or use a UTF-16 aware decoder.6C6C6548. This page reads the run left to right, so you get "lleH". Switch the memory view to single bytes before copying.C1 means A, decodes to flagged bytes here.�. Seeing several of those usually means the source was Windows-1252 all along.Decoding runs in your browser. Nothing you paste leaves the page.
Tags in the output, ambiguous input, encodings above 7F.
Those are bytes 0D 0A, the line ending used by HTTP headers or Windows text files. Change Control codes to "Keep as real characters" for real line breaks in the copied text, or to "Strip" to drop every control code except tab, CR or LF.
The byte sits above 7F, outside ASCII. In Windows-1252, E9 is é. In UTF-8, E9 opens a three byte sequence, meaningless alone. Pick the encoding under "Bytes above 7F" once you know where the data came from.
Hex. The 6C token holds a letter, so no decimal reading fits. The five bytes decode to Hello. Tokens made only of two digits, like 48 65 72, fit both readings. Auto treats those as hex, then says so in the status line.
The bytes do not form a valid UTF-8 sequence. A lone E9 between plain letters is the classic case: Latin-1 or Windows-1252 text read as UTF-8. Switch "Bytes above 7F" to Windows-1252. The accented letters come back.
A quoted string. Printable characters stay as they are. Tab, CR or LF become \t, \r or \n. Everything else written as \xHH. Paste the result straight into JavaScript, Python or C source as a test fixture.
Use the Text to ASCII converter for decimal codes or the String to Hex tool for a hex dump. Pasting the result back here makes a quick round-trip check.
