What XOR Encryption Online Actually Does
XOR encryption online applies a repeating-key exclusive OR operation to UTF-8 text, producing a reversible ciphertext that you can copy as hexadecimal or Base64 and recover with the same key. For a beginner, the idea is simple: every byte of your plaintext is combined with a byte from your key using XOR, a bitwise operation that returns 1 only when the input bits differ, and the key repeats from the start when your message is longer than the key. Because XOR is its own inverse, running the same operation again with the same key restores the original bytes, which is why a single tool can encrypt and decrypt. XOR Encryption Online does this entirely in your browser, gives you both hex and Base64 representations of the same bytes, and validates UTF-8 on decrypt so you can spot wrong keys quickly.
The convention used by the tool is deliberately explicit so two users on different computers get the same answer. Both plaintext and key are encoded as UTF-8. Each plaintext byte is combined with the corresponding key byte using XOR, and when the input runs longer than the key, the key starts again from position zero. This repetition pattern is what gives "repeating-key XOR" its name. Switching the output format does not change the underlying ciphertext; hex and Base64 are simply two ways to write the same byte sequence.
Why This Tool Fits Beginners
XOR Encryption Online is designed for clarity rather than cryptographic strength, which makes it ideal for someone learning the concept for the first time. It runs entirely in the browser, so nothing about your message, your key, or your output is uploaded to a server. You see both hex and Base64 representations of the same result at the same time, so you do not have to guess which one your recipient expects. The interface forces you to pick the matching representation when decrypting, which prevents the common beginner mistake of pasting hex bytes into a field that expects Base64.
The tool also enforces limits that protect you from silent confusion. An empty input or an empty key is rejected instead of producing a meaningless result. Decryption performs fatal UTF-8 validation, so a wrong key that produces invalid byte sequences will surface as a clear error rather than as silent replacement characters. Input and key data are capped at 100,000 bytes so the page stays responsive even with very long messages. These design choices mean you spend less time guessing whether the tool is broken and more time understanding what XOR actually does.
Encrypt a Message with XOR Encryption Online
Follow these steps to produce a reversible ciphertext from any UTF-8 plaintext using a repeating key.
- Open XOR Encryption Online in your browser.
- Choose the encrypt mode at the top of the page.
- Type or paste your plaintext into the message field. The text is treated as UTF-8, so emoji, accents and non-Latin scripts are all allowed.
- Type the repeating key into the key field. Use the exact characters you intend to share, including case and spaces.
- Run the local XOR transform. The page encodes both inputs as UTF-8 bytes using the browser's TextEncoder, then XORs each plaintext byte against keyBytes[index modulo keyLength] following the standard bitwise XOR rule.
- Copy the hex or Base64 representation you plan to send. Both are displayed so you can choose either.
- Tell the recipient which representation you used and the exact key text, character for character.
Worked example. Plaintext "Hi" with key "k". The UTF-8 bytes are 'H' = 0x48, 'i' = 0x69 and 'k' = 0x6B. Byte 0: 0x48 XOR 0x6B = 0x23. Byte 1: 0x69 XOR 0x6B = 0x02. The ciphertext is the two-byte sequence 0x23 0x02, which writes as the four-character hex string 2302 and the Base64 string IwI=.
Decrypt a Message with the Same Tool
Decryption uses the same page with a different mode. The two participants must agree on the exact key text and the exact representation of the ciphertext; otherwise the recovered bytes will not match the original plaintext.
- Open XOR Encryption Online.
- Switch the page to decrypt mode.
- Choose the representation that matches what was sent, either hex or Base64.
- Paste the ciphertext into the matching input field. The page parses strictly: hex must contain complete byte pairs and only hexadecimal digits (whitespace is ignored), while Base64 must use the standard alphabet with correct padding.
- Enter the identical key, character for character, including case and spaces.
- Read the recovered plaintext. If the result looks like garbled symbols or the page reports a UTF-8 decoding error, the key is almost certainly wrong.
- Confirm meaningful plaintext through a second channel. A successful UTF-8 decode proves the bytes form valid characters, not that you used the right key, because some wrong byte sequences happen to land on valid characters, especially with short ASCII messages.
The same byte sequence also decrypts correctly through any tool that follows the same UTF-8 plus repeating-key convention. If you compare results against a command-line program or a programming library and they disagree, the most common cause is a different key convention. The other tool may treat the key as hex bytes, may work on UTF-16 code units, or may use a different repetition rule, and any of those will produce different ciphertext from the same visible key.
Hex or Base64: Which Format Should You Send
Both representations encode the exact same bytes. The difference is purely how the byte sequence is written down, which matters when you copy the ciphertext into chat, an email, a code file, or a forum post.
| Aspect | Hex | Base64 |
|---|---|---|
| Characters used | 0-9 and a-f (lowercase) | A-Z, a-z, 0-9, +, / and = padding |
| Output length | Two characters per byte (longer) | About 1.33 characters per byte (shorter) |
| Best for | Inspecting individual bytes, debugging, embedding in code comments | Carrying ciphertext through text fields, URLs and JSON |
| Strict parsing rules | Complete byte pairs, hex digits only, whitespace ignored | Standard alphabet, correct padding |
| Readable by humans | Easy to count and split into bytes | Shorter, harder to edit by hand |
Pick hex when you want to inspect or compare individual bytes, when the recipient is a developer pasting the ciphertext into a script, or when the receiving system already documents a hex interface. Pick Base64 when the ciphertext has to fit through a text field, a URL parameter, or a JSON payload, or when you simply want a shorter string to copy and paste. The XOR ciphertext itself is unchanged; only the representation differs. For a longer reference on these two formats and on key conventions, see the XOR Encryption Online cheat sheet on formats and keys.
Why the Key and Encoding Details Matter
Three details routinely trip up beginners and are worth memorising before you send the first real message. First, the key field is treated as UTF-8 text, not as hexadecimal bytes. The key word "key" becomes the three UTF-8 bytes 6B 65 79, not the single byte 0x6B. If you enter the visible string "6B6579", the tool will instead use the six ASCII bytes 36 42 36 35 37 39. This is a common source of mismatch with command-line tools and cryptography libraries.
Second, the key repeats from the beginning every time it runs out, so a two-character key used on a ten-character message cycles through positions 0, 1, 0, 1, 0, 1, 0, 1, 0, 1. Because Unicode text can occupy several bytes per visible character, emoji and many non-Latin scripts consume multiple key positions per glyph. The tool XORs UTF-8 bytes rather than JavaScript UTF-16 code units or user-perceived grapheme clusters, which is the convention that keeps results reproducible across standards-compliant browsers.
Third, whitespace inside plaintext is significant. If your plaintext contains a trailing space or a newline, that whitespace is part of the input and produces different ciphertext. Whitespace inside the encoded ciphertext, on the other hand, is ignored when parsing, which is what lets you paste a hex string with spaces between byte pairs. No other cleanup, case folding, or guessing is performed, so what you type is exactly what the tool sees.
What Repeating-Key XOR Can and Cannot Do
Repeating-key XOR is a reversible transformation, which makes it excellent for learning, for interoperability checks, and for puzzles like capture-the-flag exercises. You can use the same XOR Encryption Online tool to agree on a key, encrypt a message, send the result as hex or Base64, and let the recipient recover the plaintext. Because the page does not upload anything, the message stays on your machine the whole time.
It is not modern encryption, and the tool is explicit about that. There is no checksum, no authentication tag, no salt, no nonce, no password stretching, and no key management. Repeating keys expose patterns that make the ciphertext easier to analyse. Known plaintext can reveal key bytes. Short keys are especially weak. An attacker who can alter the ciphertext can do so without detection because there is no integrity check. The tool surfaces these limits in its own warnings, and a familiar encryption label must not imply protection that repeating-key XOR cannot provide. For a deeper discussion of these limits, see Is XOR Encryption Secure? A Repeating-Key Reality Check.
Do not use this page to protect passwords, personal records, payment details, private keys, or any information where confidentiality or integrity matters. For real security, choose a reviewed authenticated cipher that handles keys safely, such as the AES-256-GCM package produced by AES Encryption Online, and never reuse a chat-app key for a sensitive purpose. Treat repeating-key XOR for what it is: a teaching tool and a reversible puzzle format, not a privacy mechanism.