XOR Encryption: Encode and Decode Text

How to use the xor encryption tool

1. Select Encrypt or Decrypt from the mode dropdown.
2. Choose the Input format that matches your data: plain text, hexadecimal or base64.
3. Paste your text or ciphertext into the Input field.
4. Enter a Key. The key repeats across the entire input during processing.
5. Pick an Output format and read the result below. Hex or base64 is best for encrypted output.

How XOR encryption works

XOR encryption applies the bitwise exclusive OR operator to each byte of the input against a repeating key. The core formula is C[i] = P[i] ^ K[i mod L], where P is the plaintext byte, K is the key byte and L is the key length.

Because XOR is its own inverse, applying the same operation again recovers the original data: P[i] = C[i] ^ K[i mod L]. For example, encrypting the letter "A" (byte value 65) with the key "B" (byte value 66) gives 65 ^ 66 = 3. Decrypting byte 3 with key "B" gives 3 ^ 66 = 65, which is "A" again.

Worked example with a repeating key

Consider the plaintext "hello" and the key "key". First, convert both to their UTF-8 byte values:

The final hex ciphertext is 030015070a. To decrypt, feed this hex string back into the tool with the same key and it will reverse every step.

Input and output formats

This tool supports three formats so you can integrate xor encryption into different workflows:

• Plain text (UTF-8): Characters are encoded as UTF-8 bytes before XOR. Use this for readable input and output, but be aware that encrypted bytes may include control characters that terminals or editors cannot display properly.
• Hexadecimal: Each byte becomes two lowercase hex digits (0 through 9, a through f). This is the safest way to transport ciphertext because it only uses printable ASCII characters.
• Base64: Bytes are grouped into 24-bit blocks and encoded as four printable characters. Base64 output is roughly 33 percent longer than the raw bytes but is widely supported in APIs and configuration files.

When decrypting, set the input format to match how the ciphertext was originally encoded.

Security considerations

XOR encryption with a short repeating key is not secure against modern analysis. If the key is shorter than the message, patterns in the plaintext leak through. An attacker who knows part of the plaintext can recover the corresponding key bytes and use them to decrypt the rest of the message.

A single-byte key is trivially broken by frequency analysis: the most common byte in the ciphertext likely corresponds to a space or the letter "e" in English text. For serious protection, use established algorithms like those found in the AES encryption tool instead.

The one scenario where XOR is perfectly secure is the one-time pad, where the key is truly random, at least as long as the message and never reused. You can generate random keys with tools like the one-time pad generator.

Common uses for XOR ciphers

Despite its simplicity, xor encryption appears frequently in software engineering and security research:

• Obfuscation: Hiding strings in binaries so they do not appear in plain text when someone runs the strings command.
• Lightweight encoding: Masking data in custom network protocols or file formats where full cryptography is unnecessary overhead.
• Malware analysis: Many malicious payloads use multi-byte XOR keys to hide their code. Analysts routinely write scripts to brute-force short keys.
• Educational exercises: Learning how symmetric operations work before studying block ciphers or stream ciphers.

In all these cases, remember that XOR alone does not provide authentication or integrity checking. Pair it with a checksum or hash if tampering is a concern.

Worked examples