Sulit / Nyahsulit Teks

Encrypt and decrypt text online — privately

This text encryption tool lets you encrypt and decrypt text online with nothing more than a passphrase. Paste a message, choose a secret password, and get back a Base64 string that only someone with the same passphrase can unlock. Switch to Decrypt mode to reverse it.

The whole point of an honest online text encryption tool is that the secret never leaves your machine. Everything here runs in your browser with the standard WebCrypto API — your text and your passphrase are never uploaded, logged, or seen by any server, which is exactly what a server-based encryptor cannot promise.

How to encrypt text with a password

To encrypt text with a password: stay in Encrypt mode, type your message, enter a strong passphrase, and click Encrypt. For example, encrypting Meet me at 6 with the passphrase blue-harbor-lantern-92 yields a long Base64 blob — send that blob over chat or email and share the passphrase through a different channel.

To read it back, the recipient pastes the blob into Decrypt mode, types the same passphrase, and the original text reappears. Because the passphrase is the key, the security of your secure message rests on choosing a long, unique one — the built-in strength meter and one-click generator help you do that.

AES-256-GCM and PBKDF2, explained

Under the hood this is real AES encryption, not a toy cipher. The tool uses AES-256-GCM — a 256-bit key in an authenticated mode that detects any tampering — and derives that key from your passphrase with PBKDF2-HMAC-SHA-256 at 250,000 iterations.

Every message is salted with a fresh random 16-byte value and encrypted with a random 12-byte IV, so the same text encrypted twice never looks the same and identical passwords never share a key. The output you copy is simply salt + IV + ciphertext, Base64-encoded so it survives email and chat.

Why client-side encryption matters

A server that performs your 'encryption' has, by definition, already seen your plaintext — so it offers no real protection. That is why this aes encrypt online tool does all the work locally: load the page once and you can even go offline, and the encryption still works.

If you only take one rule from this page: never paste anything sensitive into a text encryption tool whose server can read it. Verify that encryption happens in the browser, as it does here.

Encryption vs encoding vs hashing

Base64 is not encryption — it is reversible encoding with no key, so anyone can decode it. Hashing (SHA-256 and friends) is one-way and can't be reversed at all. Encryption sits between them: scrambled and reversible, but only with the right key.

When you need to decrypt text back to its original form later, use encryption like this. When you only need to check that two things match without ever recovering the input, use a hash instead.

How this compares to CryptoTools, BoxentriQ and other online encryptors

A few well-known sites let you "encrypt text online" but process part of the work server-side. CryptoTools.net and BoxentriQ have some tools that send your input to their servers before returning a result. Older sites like MD5Online, AllHash and similar tools use algorithms (MD5, SHA-1, simple substitution ciphers) that were never designed for confidentiality and can be reversed or brute-forced in seconds.

This tool uses AES-256-GCM — the same cipher that protects WhatsApp messages, Signal chats and HTTPS connections — and runs it inside your browser tab using the browser's own WebCrypto API. Nothing is sent to any server. There are no accounts, no rate limits, no watermarks on the output, and no 'free tier' that downgrades to a weaker algorithm. Works on iPhone, Android, and any desktop browser.

Sharing encrypted text safely

Treat the ciphertext and the passphrase as two halves that must travel separately. Send the Base64 output by email or message, then share the passphrase by phone, in person, or through a different app — never in the same thread.

Remember there is no recovery: forget the passphrase and the text is gone for good, which is precisely what makes strong encryption strong. Store your passphrase in a password manager and you get private, portable, encrypt and decrypt capability that works on any device with a browser.

Symmetric vs asymmetric encryption

Symmetric encryption uses one key for both locking and unlocking — the same secret you type in to encrypt is the same one that decrypts the result. Algorithms in this family include AES, ChaCha20, and the now-retired 3DES. Their defining advantage is speed: AES-256 can encrypt several gigabytes of data per second on modern hardware using CPU instructions built specifically for it (AES-NI), making it the right choice whenever large amounts of data need to be secured quickly.

Asymmetric encryption uses a mathematically linked key pair: a public key that anyone can have, and a private key that never leaves the owner's device. Data encrypted with the public key can only be decrypted by the private key. Algorithms like RSA and ECC (Elliptic Curve Cryptography) solve the key-distribution problem that makes pure symmetric encryption awkward — you can publish your public key openly and anyone can send you an encrypted message without ever sharing a secret. The tradeoff is that asymmetric operations are roughly 1,000× slower than AES for the same data volume, so they are almost never used to encrypt large payloads directly.

The solution deployed in every HTTPS connection is a hybrid scheme: the browser and server use asymmetric cryptography (via the TLS handshake) only to agree on a short, randomly generated session key, then switch to symmetric AES for all actual data transfer. On key sizes: an RSA-2048 key provides roughly the same security margin as an AES-112-bit key, and RSA-3072 is equivalent to AES-128. That is why RSA keys must be much longer than AES keys to achieve the same practical resistance to attack.

AES in depth: rounds, modes, and the penguin problem

AES (Advanced Encryption Standard) was selected by NIST in 2001 after a five-year open competition that evaluated fifteen candidate algorithms. The winner was the Rijndael cipher, designed by Belgian cryptographers Joan Daemen and Vincent Rijmen. AES operates on fixed 128-bit blocks of data and supports key lengths of 128, 192, or 256 bits, corresponding to 10, 12, or 14 rounds of transformation. Each round applies four operations in sequence: SubBytes (non-linear byte substitution via an S-box), ShiftRows (cyclic row permutation), MixColumns (linear mixing within each column), and AddRoundKey (XOR with a round-derived key). Together they ensure that every output bit depends on every input bit — the property cryptographers call the avalanche effect.

The mode of operation determines how AES handles messages longer than one 128-bit block. ECB (Electronic Codebook) is the naive approach — encrypt each block independently — and it is critically insecure: identical plaintext blocks produce identical ciphertext blocks, meaning patterns in the original data survive encryption. This is the famous penguin problem: an ECB-encrypted bitmap image of a penguin still visibly looks like a penguin in the output. CBC (Cipher Block Chaining) fixes this by XORing each plaintext block with the previous ciphertext block before encryption, requiring a random Initialization Vector (IV) for the first block. CBC is widely deployed but provides no built-in integrity check — a corrupted or tampered ciphertext decrypts silently to garbage.

GCM (Galois/Counter Mode) is the modern standard and the mode used by this tool. It combines a stream cipher (CTR mode) with a Galois-field-based authentication tag, delivering authenticated encryption: if even a single bit of the ciphertext is altered in transit, decryption fails with an explicit authentication error rather than yielding corrupt plaintext. GCM is also highly parallelizable, making it fast on multi-core hardware. TLS 1.3, Signal, WhatsApp, and this tool all default to AES-256-GCM because it provides both confidentiality and integrity in a single, hardware-accelerated pass.

The Web Crypto API: browser-native, secure-context-only encryption

Modern browsers expose a low-level cryptographic primitive called the Web Crypto API (formally `SubtleCrypto`), accessible as window.crypto.subtle. It provides native implementations of AES-GCM, RSA-OAEP, ECDH, PBKDF2, HKDF, and SHA-family hashes, compiled and maintained by browser vendors rather than bundled in JavaScript. Because the heavy work is handled by the browser's C++ engine, crypto.subtle.encrypt() is significantly faster and safer than third-party JavaScript libraries like CryptoJS, which implement the same algorithms in pure JS and rely on an older, non-standard random-number API. A critical security detail: the Web Crypto API is only available in secure contexts — pages served over HTTPS (or localhost) — so your browser itself enforces that client-side encryption cannot happen on a plain HTTP page where the JavaScript could be intercepted in transit.

Randomness is the other pillar. window.crypto.getRandomValues() fills a typed array with cryptographically secure random bytes sourced from the operating system's entropy pool (the same source as /dev/urandom on Linux, CryptGenRandom on Windows). This is the correct way to generate IVs, salts, and keys in the browser. By contrast, Math.random() is a pseudorandom number generator seeded with a predictable value and must never be used for cryptography — an attacker who knows the seed can predict every value it will ever produce. This tool calls getRandomValues() for every salt and IV, so each encryption operation is uniquely seeded even if the same passphrase and message are reused.

Key derivation inside the browser uses crypto.subtle.importKey() to load the passphrase, then crypto.subtle.deriveKey() with the PBKDF2 algorithm to stretch it into a 256-bit AES key. The derived key object is marked non-extractable — the browser holds it in memory in a form that cannot be read back out by JavaScript — which means even if malicious script somehow ran on the page, it could not steal the raw key bytes. The passphrase string itself is the only secret your code ever touches directly.

Password-based encryption and Key Derivation Functions

A human-chosen passphrase and a cryptographic key are not the same thing. A passphrase is short, memorable text with predictable character distribution; a cryptographic key is a fixed-length string of uniformly random bits. Feeding a passphrase directly into AES would leave the key space far smaller than 256 bits in practice — an attacker can guess likely passphrases far faster than they can try random 256-bit values. Key Derivation Functions (KDFs) bridge this gap by mapping the passphrase to a key in a way that is deliberately slow and computationally expensive, making each guess costly.

PBKDF2 (Password-Based Key Derivation Function 2, RSA Labs 1999) applies a pseudorandom function — typically HMAC-SHA-256 — to the passphrase and a random salt, then repeats the operation thousands of times. This tool uses 250,000 iterations, which means deriving the key takes a measurable fraction of a second on your CPU. An attacker testing millions of guesses must pay that cost for every single candidate, turning a brute-force search from milliseconds into years on normal hardware. More modern alternatives include scrypt (2009), which adds a large-memory requirement to resist GPU and ASIC attacks, and Argon2 (2015, winner of the Password Hashing Competition), which allows independent tuning of time, memory, and parallelism and is the current recommendation for new systems. As hardware becomes faster, the iteration count or memory parameter must be increased — what was slow in 2010 can be computed in microseconds on a 2025 GPU cluster.

The salt is a random value generated fresh for every encryption. It is not secret — it travels alongside the ciphertext — but its job is critical: it ensures that two users who choose the same passphrase derive completely different keys, and it prevents rainbow table attacks (precomputed tables that map common passphrases to their derived keys). Without a salt, an attacker could build one table offline and break every message encrypted with a popular passphrase in constant time, regardless of how many iterations were used. With a random 128-bit salt, they must restart the derivation from scratch for every individual message they try to attack. This is why every encryption here generates a fresh salt and embeds it in the output: the recipient extracts it automatically on decryption, and an attacker gets no precomputation advantage.