Guide
XOR with a key, and recovering a one-byte XOR key
Exclusive-or, written XOR, is the simplest operation in cryptography and one of the most common in malware. Take two bits and the result is 1 only when they differ. Line up two byte strings, one holding your data and one a key, apply that rule to every bit, and you get a scrambled copy that anyone holding the key can restore by applying XOR again. This page does the operation for data in several formats and includes a breaker for the case where you hold only the scrambled bytes.
How the operation works
Write the letter H as the byte 0x48 and the letter k as 0x6B. In binary those are 01001000 and 01101011, and XOR gives 00100011, which is 0x23. The key is stretched by repeating it until it covers the data: a three-byte key key applied to twelve bytes is used four times in a row. Because the same step reverses itself, there is no separate decrypt mode. Feed the result back in with the same key and the original returns.
A worked example
Press Sample on the data field to load “Hello, world”, then Sample on the key field to load “key”. The page shows the result 230015070a554b121619091d in hex, IwAVBwpVSxIWGQkd in Base64, and #....UK..... as text with dots for the control bytes. You can check the first byte by hand as above. The second byte is e XOR e, which is 00: where the data letter equals the key letter the output is a zero byte. Paste the hex back as data, choose hex as its format, keep the key, and “Hello, world” comes back.
Breaking a single-byte key
Switch the mode to “Break single-byte XOR” and paste or open the scrambled data, often as hex copied from a malware sample or a puzzle. The page tries all 256 possible keys, scores each output by how much it looks like English text and shows the eight best, with the key in hex and decimal and the first characters of the result. A readable line near the top usually gives the key at once.
Edge cases
Data and key bytes are matched position by position, so a key longer than the data uses only its first bytes and the page says so. A key of zero length produces a warning and no result. Text input is converted to bytes as UTF-8, so a character such as é takes two bytes and affects two key positions. When XORing with Base64 or hex data, check you picked the right input format; a hex string read as text produces a different, wrong result.
Limits
XOR with a short repeating key is not encryption you should rely on: it falls to frequency analysis, and with known plaintext the key can be read off directly. Only a random key as long as the message and never reused is secure. The breaker handles one-byte keys and English-like plaintext; it will not recover multi-byte keys or text in other languages with confidence.
Related tools
- Hex to Binary converts the values in a result.
- Hex Editor shows bytes in a file before you XOR them.
- CRC Calculator computes a checksum of the recovered data.
- Base64 Encoder handles the Base64 form of the same bytes.
Checked against the current version of the XOR Calculator on .

