Encryptor & Decryptor

Why browser-side cryptography?

The SubtleCrypto API (window.crypto.subtle) has been available in all major browsers since 2017 and uses the same underlying OS cryptographic primitives as Node.js's crypto module. That means you get real, production-grade AES-256-GCM and RSA-OAEP without installing anything or trusting a third-party server with your secrets.

The tool is useful for developers who want to test encryption logic interactively, security professionals who need a quick way to encrypt a config snippet before sharing it, and anyone who wants to understand how these algorithms work in practice.

The privacy benefit of doing cryptographic work entirely in the browser is significant but also limited in a specific way that is worth understanding clearly. Because the computation happens inside your browser tab using the SubtleCrypto API, your plaintext, your password, and the resulting ciphertext are never transmitted over the network. There is no server log that could expose them, no request payload that could be intercepted, and no third-party service to trust. That is a genuine security advantage over online tools that perform encryption server-side.

However, browser-side encryption does not protect you from everything. If your browser or operating system is compromised, a malicious script could intercept data before it is encrypted. For high-value secrets in production systems, dedicated tooling with proper key management infrastructure — such as a hardware security module (HSM) or a secrets manager — remains the right choice. The browser tool is excellent for learning, for developer testing, and for encrypting lower-stakes content when you need something immediately available.

Symmetric vs asymmetric encryption

Before diving into the specific algorithms, it is useful to understand the fundamental split in modern cryptography. Encryption schemes fall into two broad families: symmetric and asymmetric. Each solves a different problem, and knowing which to reach for in a given situation makes you a more effective developer.

Symmetric encryption uses a single shared key for both encryption and decryption. The sender and the receiver must both know the same secret. AES is the dominant symmetric cipher in use today. Symmetric algorithms are very fast — they can encrypt gigabytes of data per second on modern hardware — but they have a fundamental distribution problem: how do you securely get the shared key to the other party in the first place? If you could already communicate securely, you would not need encryption. This is called the key exchange problem.

Asymmetric encryption (also called public-key cryptography) solves the key exchange problem by using two mathematically linked keys: a public key and a private key. Anything encrypted with the public key can only be decrypted with the corresponding private key. You can publish your public key to the world. Anyone can encrypt a message to you, but only you — with your private key — can read it. RSA is the most widely known asymmetric algorithm. The trade-off is that asymmetric operations are orders of magnitude slower than symmetric operations, which is why protocols like TLS use asymmetric cryptography only to establish a shared symmetric session key, and then switch to AES for the bulk of the data transfer.

AES-256 encryption

AES stands for Advanced Encryption Standard. It was selected by the US National Institute of Standards and Technology (NIST) in 2001 after a five-year public competition and has been the dominant symmetric cipher in the world ever since. Banks, governments, messaging applications, VPNs, full-disk encryption tools, and TLS all rely on AES. Understanding what the numbers mean helps you make informed choices.

The number after AES refers to the key size in bits. AES supports three key sizes: 128-bit, 192-bit, and 256-bit. All three are considered secure against brute-force attacks for any foreseeable future. AES-128 has 2^128 possible keys; AES-256 has 2^256. To put that in perspective, AES-128 alone has more possible keys than there are atoms in the observable universe by many orders of magnitude. AES-256 is chosen for the highest-security contexts — US government classified information requires it — but AES-128 is also perfectly adequate for most civilian use. This tool uses AES-256 because there is no meaningful performance cost in a browser context when encrypting text snippets.

The mode of operation matters as much as the key size. AES is a block cipher — it operates on 128-bit (16-byte) blocks of data at a time. The mode determines how those blocks are chained together and what security properties the scheme has. Some modes, like ECB (Electronic Codebook), are dangerously weak: identical plaintext blocks produce identical ciphertext blocks, which leaks pattern information. The classic demonstration is encrypting a bitmap image with ECB — you can still see the shapes of the original image in the ciphertext. This tool uses GCM (Galois/Counter Mode), which is an authenticated encryption mode. GCM provides both confidentiality and authenticity: if the ciphertext is tampered with even by a single bit, decryption will fail with an authentication error rather than silently returning corrupted data. That tamper detection is critical for security. Other secure modes include CBC with HMAC and ChaCha20-Poly1305, but GCM is the standard choice in the Web Crypto API.

Base64 is encoding, not encryption

This is one of the most common and dangerous misconceptions in software development, and it is worth addressing directly. Base64 is an encoding scheme, not an encryption algorithm. It converts binary data into a set of 64 printable ASCII characters (A–Z, a–z, 0–9, and + and /), making it safe to transmit in contexts that only handle text — such as email, JSON payloads, or URL parameters. It provides zero confidentiality. Anyone who receives Base64-encoded data can decode it instantly using any standard library or a single command-line call. There is no key, no secret, and no barrier whatsoever.

The reason this matters so much is that developers sometimes store Base64-encoded data and mistakenly believe it is protected from casual inspection. The characteristic padding characters at the end of a Base64 string — the equals signs — are recognizable to any competent attacker, and automated tools routinely scan for and decode Base64 strings in leaked credentials, configuration files, and API responses.

In this tool, Base64 is used only as a transport format for the output of AES-256-GCM encryption. The actual security comes from the AES encryption itself — the Base64 layer just makes the binary ciphertext safe to paste into a text field, store in a JSON document, or copy into an email. The output looks like a long string of random characters; that opacity is because it is genuinely encrypted binary data rendered in Base64 form, not because Base64 hides it.

Hashing vs encryption — a critical distinction

Encryption and hashing are both operations that transform data, but they serve completely different purposes and should never be confused. Using the wrong one for a given task can create serious security vulnerabilities.

Encryption is a two-way operation. Given the correct key, you can always recover the original plaintext from the ciphertext. This is the point: encryption protects data in transit or at rest when you need to read it later. Use encryption for: protecting a configuration file that your application needs to read, securing a message that a recipient needs to decrypt, or storing data that must be retrieved in its original form.

Hashing is a one-way operation. A cryptographic hash function takes input of any size and produces a fixed-size output (called a digest or hash). There is no key and no reverse operation. You cannot recover the original input from a hash. Common hash functions include SHA-256, SHA-3, and bcrypt. Hashing is the correct approach for storing user passwords in a database. When a user logs in, you hash the provided password and compare it to the stored hash. If they match, the password is correct — and you never need to store or recover the original password. If your database is compromised, attackers get only hashes, not the original passwords.

The critical rule: never encrypt passwords stored in databases — always hash them using a password-specific algorithm like bcrypt, scrypt, or Argon2. These algorithms are deliberately slow and include a salt to prevent precomputed attacks. Standard hash functions like SHA-256 are designed to be fast, which makes them unsuitable for password storage because attackers can compute billions of guesses per second on GPU hardware.

RSA key pair generation

The RSA generator creates 2048-bit or 4096-bit RSA-OAEP key pairs using SubtleCrypto's generateKey. Keys are exported in PEM format (PKCS#8 for private, SPKI for public) so they can be used directly with OpenSSL, Node.js, Python's cryptography library, or any other standard implementation.

RSA key size directly determines the security margin against factoring attacks. A 2048-bit RSA key is the current industry minimum recommended by NIST and is considered secure for most use cases through at least the mid-2030s. A 4096-bit key provides a larger margin against future advances in classical computing and is preferred in high-security contexts, though key generation and encryption operations are noticeably slower. For context, RSA security is based on the mathematical difficulty of factoring the product of two large primes — a problem for which no efficient classical algorithm is known, though quantum computers (using Shor's algorithm) could eventually break RSA if sufficiently powerful quantum hardware becomes available.

This tool is useful when you need a quick key pair for testing, prototyping an asymmetric encryption scheme, or setting up a new SSH or TLS configuration in a development environment. Keep in mind that for any key pair intended for real use, you should store the private key in a secure location (a password manager, a hardware key, or a dedicated secrets store) and never transmit it over unencrypted channels. The public key can be freely shared.

The role of keys, passwords, and key strength

Encryption is only as strong as the key protecting it. This sounds obvious but has important practical implications that are frequently overlooked in real systems. AES-256 cannot be broken by brute force with any conceivable computing power — but a weak or reused password used as the basis for key derivation can undermine that strength entirely.

When you enter a password into the AES encryption form, the tool does not use that password directly as the 256-bit AES key. Instead, it runs the password through PBKDF2 (Password-Based Key Derivation Function 2) with SHA-256 as the underlying hash, a random 128-bit salt, and 100,000 iterations. The salt ensures that even if two people use the same password, their derived keys will be different. The high iteration count means that even a fast GPU, which might compute billions of simple SHA-256 hashes per second, is slowed to a rate of thousands or fewer PBKDF2 iterations per second — making brute-force guessing of the password vastly more expensive.

Despite PBKDF2's hardening, a short or common password remains vulnerable. A dictionary attack against a password like "password1" will succeed no matter how many iterations PBKDF2 uses, because the attacker simply starts from a list of known bad passwords. This is why password quality matters — a 20-character random password of mixed character types has an entropy that makes brute force infeasible even with no key stretching at all. Use the password generator included in this tool to create strong encryption passwords.

Password strength checker & generator

The difference between Math.random() and crypto.getRandomValues() is not just academic. JavaScript's Math.random() is a pseudorandom number generator (PRNG) seeded from a non-secret value. An attacker who observes enough outputs from it can predict future outputs, which means passwords generated with it could be predicted. The Web Crypto API's crypto.getRandomValues() draws from the operating system's entropy pool (which is seeded from hardware events like disk timing and interrupt timing) and is cryptographically unpredictable. This tool exclusively uses the secure variant.

When to use encryption — and when not to

Encryption is a powerful tool but not a universal solution. Applied incorrectly, it can create a false sense of security. Here are concrete scenarios where encryption is the right call, and some common situations where it is misapplied or misunderstood.

Encrypt: configuration secrets (API keys, database connection strings) stored in files or databases; personal data at rest in a database that regulations require to be protected (healthcare data, financial records); messages between parties who do not trust the channel; backups stored on third-party cloud services; and sensitive notes or documents stored locally that you want protected if your device is lost or stolen.

Do not rely on encryption alone: for authentication (encryption confirms nothing about who sent a message without a separate signature); for passwords stored in a user database (use hashing); for protecting data from your own infrastructure — if your server is fully compromised, the encryption key is also compromised. Encryption protects data from parties who do not have the key, not from everyone.

Finally, key management is the hardest part of any encryption scheme. A perfect implementation of AES-256 is useless if the key is stored in a plain text file in the same repository as the encrypted data, checked into version control, or left in an environment variable that is logged to standard output. The weakest link in most real-world encryption failures is not the cipher — it is the handling of the key.

Frequently Asked Questions