Web-Crypto | Toolbox Guides & Articles

RSA vs ECC Keypairs: Key Sizes, PEM Formats, and Choosing a Curve in 2026

Sun, 06 Sep 2026 00:00:00 +0000

Interactive Workbench LIVE

RSA vs ECC Keypairs: Key Sizes, PEM Formats, and Choosing a Curve in 2026

Open Fullscreen ↗

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

Free In-Browser Tool TOOLBOX UTILITY

RSA & ECC Keypair Generator

Generate RSA keypairs in PKCS#8 and SPKI PEM using the browser's own Web Crypto implementation. Private key material never leaves local memory.

Open Air-Gapped Keypair Generator →

Two Ways to Build a Trapdoor

Asymmetric cryptography needs a function that is easy forwards and infeasible backwards. RSA and ECC pick different hard problems:

RSA (RFC 8017) relies on the difficulty of factoring a modulus n = p × q into its two large primes. Public key: (n, e). Private key: (n, d) plus the CRT parameters that make decryption fast.
ECC relies on the elliptic curve discrete logarithm problem: given points G and Q = kG on a curve, recover the scalar k. Public key: the point Q. Private key: the scalar k.

The consequence is not academic. The best classical attack on RSA — the general number field sieve — runs in sub-exponential time, so RSA key sizes must grow steeply to keep pace with hardware. The best generic attack on a well-chosen curve is Pollard’s rho at roughly the square root of the group order, so ECC key sizes grow linearly with security. That single difference explains the entire comparison table below.

What you get from this guide: a defensible key-size choice, the ability to read any PEM file you are handed, and a clear view of what post-quantum migration does and does not demand of you today.

Security Strength: The Only Fair Comparison

Key length is meaningless across algorithm families. The comparable unit is security strength in bits, expressed as the equivalent symmetric key.

Security strength	RSA modulus	Elliptic curve	Symmetric equivalent
112 bits	RSA-2048	P-224	3TDEA (legacy)
128 bits	RSA-3072	P-256 (secp256r1)	AES-128
192 bits	RSA-7680	P-384 (secp384r1)	AES-192
256 bits	RSA-15360	P-521 (secp521r1)	AES-256

Two practical readings of this table:

RSA-2048 is the current floor, not a target. It sits at 112-bit strength, which NIST’s transition guidance schedules for phase-out by 2030 and disallowance by 2035. New long-lived keys should be RSA-3072 or an elliptic curve.
RSA-4096 is not the obvious upgrade. It buys roughly 140 bits of strength for four to eight times the signing cost of RSA-3072. P-256 reaches 128 bits with a 32-byte private scalar and signs an order of magnitude faster.

Performance shape

Operation	RSA-2048	ECDSA P-256
Key generation	Slow (prime search)	Fast (one scalar multiply)
Sign / decrypt	Slow (private exponent)	Fast
Verify / encrypt	Very fast (small `e = 65537`)	Moderate
Public key size	~294 bytes (SPKI DER)	~91 bytes (SPKI DER)
Signature size	256 bytes	~64-72 bytes (DER)

RSA’s asymmetry — cheap verification, expensive signing — is why it survived so long in TLS server certificates, where a server signs once per handshake but clients verify constantly. It is also why RSA keygen in a browser can take a visible second at 4096 bits while an ECDSA keypair appears instantly.

Reading a PEM File

A PEM file is Base64-encoded DER (Distinguished Encoding Rules), the canonical binary serialisation of an ASN.1 structure, wrapped in armour lines. The header tells you exactly which structure is inside.

Header line	Structure	Contains
`-----BEGIN PUBLIC KEY-----`	SubjectPublicKeyInfo (RFC 5280)	Algorithm identifier + public key bits
`-----BEGIN PRIVATE KEY-----`	PKCS#8 PrivateKeyInfo (RFC 5958)	Algorithm identifier + private key
`-----BEGIN ENCRYPTED PRIVATE KEY-----`	PKCS#8 EncryptedPrivateKeyInfo	Passphrase-wrapped private key
`-----BEGIN RSA PRIVATE KEY-----`	PKCS#1 RSAPrivateKey (RFC 8017)	RSA parameters only, no algorithm identifier
`-----BEGIN EC PRIVATE KEY-----`	SEC1 ECPrivateKey (RFC 5915)	Curve parameters + scalar
`-----BEGIN CERTIFICATE-----`	X.509 Certificate	A signed public key — see the

The modern, algorithm-agnostic pair is PKCS#8 for private and SPKI for public; those are the two formats the Web Crypto API exports. The older PKCS#1 and SEC1 forms are algorithm-specific, which is why tooling has converged on PKCS#8.

Generating a keypair with Web Crypto

// RSA-3072 signing keypair, exported as PKCS#8 + SPKI PEM.
const { publicKey, privateKey } = await crypto.subtle.generateKey(
 {
 name: "RSASSA-PKCS1-v1_5", // or "RSA-PSS" / "RSA-OAEP" for encryption
 modulusLength: 3072,
 publicExponent: new Uint8Array([0x01, 0x00, 0x01]), // 65537
 hash: "SHA-256",
 },
 true, // extractable
 ["sign", "verify"]
);

const toPem = (der, label) => {
 const b64 = btoa(String.fromCharCode(...new Uint8Array(der)));
 return `-----BEGIN ${label}-----\n${b64.match(/.{1,64}/g).join("\n")}\n-----END ${label}-----`;
};

const privatePem = toPem(await crypto.subtle.exportKey("pkcs8", privateKey), "PRIVATE KEY");
const publicPem = toPem(await crypto.subtle.exportKey("spki", publicKey), "PUBLIC KEY");

Three details that trip people up:

publicExponent is 65537 (0x010001). It is a Fermat prime with only two set bits, making verification fast; smaller exponents such as 3 have historically enabled padding attacks in badly implemented verifiers.
Base64 lines wrap at 64 characters. Some strict parsers reject unwrapped single-line PEM.
extractable: true is required to export at all. Set it to false for keys that should stay inside the browser’s key store.

The SSH format gap

A -----BEGIN PUBLIC KEY----- block cannot be pasted into ~/.ssh/authorized_keys. OpenSSH uses its own wire encoding — an algorithm name, then length-prefixed fields, Base64-encoded onto one line:

# SPKI PEM -> OpenSSH public key line
ssh-keygen -i -m PKCS8 -f public.pem

# PKCS#8 private key -> OpenSSH private key file
ssh-keygen -p -m RFC4716 -f id_rsa

Also worth knowing: OpenSSH’s recommended key type today is Ed25519, and the Web Crypto generateKey algorithms for RSA and ECDSA do not produce it. Generate Ed25519 keys with ssh-keygen -t ed25519.

Choosing an Algorithm in 2026

Use case	Recommendation	Reasoning
New TLS server certificate	ECDSA P-256, RSA-2048/3072 as fallback	Smaller handshake; universally supported by browsers
JWT signing	ES256 (ECDSA P-256) or RS256	ES256 gives shorter tokens; see the
SSH user key	Ed25519 via `ssh-keygen`	Small, fast, no curve-parameter footguns
Legacy enterprise PKI	RSA-3072	Broadest hardware and appliance support
Encrypting data directly	Neither — use hybrid	Encrypt with , wrap the AES key with RSA-OAEP or ECDH

The RSA-OAEP Size Limit and Why Hybrid Encryption Exists

RSA does not encrypt streams. It encrypts one integer smaller than the modulus. With OAEP padding (RFC 8017) the usable plaintext is:

max plaintext bytes = k - 2 * hLen - 2

k = modulus size in bytes
hLen = hash output size in bytes

Key size	`k`	OAEP hash	Maximum plaintext
2048-bit	256 bytes	SHA-1 (20)	214 bytes
2048-bit	256 bytes	SHA-256 (32)	190 bytes
3072-bit	384 bytes	SHA-256 (32)	318 bytes
4096-bit	512 bytes	SHA-256 (32)	446 bytes

190 bytes will not hold a document, a database row, or a session payload — which is why real systems use hybrid encryption:

Generate a random AES-256 content key.
Encrypt the payload with AES-256-GCM — fast, streaming, authenticated.
Encrypt only the 32-byte AES key with RSA-OAEP (or derive it with ECDH).
Ship the wrapped key alongside the ciphertext.

That is the structure inside TLS, JWE, S/MIME, and PGP: the asymmetric half transports a key, the symmetric half does the work. See the for the symmetric side.

Signature padding: PSS or PKCS#1 v1.5?

Scheme	Status	Use when
RSA-PSS	Recommended (RFC 8017)	Any new system — randomised padding with a formal security proof
RSASSA-PKCS1-v1_5	Legacy but ubiquitous	Interoperating with existing TLS certificates and JWT `RS256`
Raw RSA, no padding	Never	Textbook RSA is deterministic and trivially malleable

Never encrypt bulk data with RSA. RSA-OAEP can encrypt at most a few hundred bytes for a given modulus. The correct pattern is hybrid encryption: generate a random symmetric key, encrypt the payload with AES-GCM, and encrypt only that symmetric key with the recipient’s public key.

Where post-quantum stands

NIST finalised three post-quantum standards in August 2024: FIPS 203 (ML-KEM) for key encapsulation, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures. FIPS 206 (FN-DSA) remains a draft as of 2026. NIST’s transition schedule phases out 112-bit-strength classical algorithms by 2030 and disallows them from 2035; NSA’s CNSA 2.0 sets 2030 for national security systems.

Shor’s algorithm on a sufficiently large quantum computer would factor RSA moduli efficiently, breaking RSA at every key size, and would solve elliptic curve discrete logarithms too. No such machine exists today, but ciphertext captured now can be stored for later decryption — the harvest now, decrypt later problem. The deployed transition path is hybrid: combine a classical key exchange with ML-KEM so the session survives if either component fails.

For an application team, the actionable version is short: do not rewrite your PKI this quarter, but stop hardcoding algorithm names, keep certificate lifetimes short so rotation is routine, and inventory where long-lived signatures and long-lived encrypted archives live — those are the assets exposed to “harvest now, decrypt later”.

Step-by-Step: Generating and Inspecting Keys with Toolbox

Open the tool: visit the .
Pick a modulus size: 2048 for legacy interoperability, 3072 for a 128-bit strength target, 4096 only when a policy demands it.
Generate: the browser’s Web Crypto implementation performs the prime search locally; nothing is sent over the network.
Copy both PEM blocks: the PKCS#8 private key and the SPKI public key. Store the private key in a secret manager immediately — a key that has been in a clipboard buffer and then an email is not a secret.
Verify the pair matches before deploying:

openssl rsa -in private.pem -pubout | diff - public.pem && echo "pair OK"
openssl rsa -in private.pem -noout -text | head -2 # confirms modulus size

Outcome: a correctly encoded, verified keypair for local development, signing tests, or PKI experiments — generated without pasting a private key into a remote web service.

Related guides: · ·

FAQ

Frequently Asked Questions

Is a 256-bit ECC key really as strong as a 3072-bit RSA key? ▼

Against classical attacks, yes. Strength is measured in equivalent symmetric bits: RSA-2048 is about 112 bits, while RSA-3072 and NIST P-256 are both about 128 bits. RSA keys must grow much faster because the general number field sieve is sub-exponential, whereas the best generic attack on elliptic curve discrete logarithms takes square-root time in the group order.

What is the difference between PKCS#8 and SPKI PEM files? ▼

PKCS#8 (RFC 5208 / RFC 5958) is the standard private-key container and starts with BEGIN PRIVATE KEY. SPKI, or SubjectPublicKeyInfo (RFC 5280), is the standard public-key container and starts with BEGIN PUBLIC KEY. Both are Base64-wrapped DER ASN.1. The older PKCS#1 form, BEGIN RSA PRIVATE KEY, carries only RSA parameters with no algorithm identifier.

Can I paste a generated PEM public key into authorized_keys for SSH? ▼

No. OpenSSH uses its own one-line format beginning with ssh-rsa, ecdsa-sha2-nistp256, or ssh-ed25519 followed by Base64 of a length-prefixed structure. Convert a SPKI PEM with ssh-keygen -i -m PKCS8 -f public.pem. Note that Ed25519, OpenSSH's preferred modern type, is not produced by the Web Crypto RSA or ECDSA algorithms.

Should I generate post-quantum keys instead of RSA or ECC today? ▼

For most TLS, SSH, and signing work RSA and ECC remain the interoperable choice in 2026. NIST finalised ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) in August 2024, while FN-DSA (FIPS 206) is still draft, and NIST schedules 112-bit-strength algorithms for phase-out by 2030 and disallowance by 2035. Prioritise crypto-agility: configurable algorithms, short certificate lifetimes, and an inventory of long-lived secrets.

AES-256-GCM Authenticated Encryption: How to Secure Data in the Browser

Sat, 05 Sep 2026 00:00:00 +0000

Free In-Browser Tool TOOLBOX UTILITY

AES Encryption & Decryption Utility

Encrypt and decrypt confidential text using AES-GCM or AES-CBC directly in your browser with hardware-accelerated Web Crypto API.

Open AES-256 Web Crypto Tool →

What Is AES and How Does Modern Symmetric Cryptography Work?

The Advanced Encryption Standard (AES), standardized by the US National Institute of Standards and Technology (NIST FIPS 197), is the gold standard symmetric block cipher protecting modern internet communications (TLS 1.3), database storage encryption, disk volumes (BitLocker, FileVault), and zero-knowledge cloud applications.

As a symmetric cipher, AES uses the same secret key for both encryption and decryption. It operates on fixed 128-bit (16-byte) blocks of data through multiple rounds of substitution and permutation operations (SubBytes, ShiftRows, MixColumns, and AddRoundKey):

AES-128: 10 rounds (128-bit key)
AES-192: 12 rounds (192-bit key)
AES-256: 14 rounds (256-bit key)

AES-256 provides a theoretical keyspace of $2^{256} \approx 1.15 \times 10^{77}$ combinations, rendering brute-force attacks physically impossible with classical computers.

The Critical Role of Block Cipher Modes

A raw block cipher can only transform a single 16-byte block of plaintext. To encrypt arbitrary-length messages or streams, a mode of operation must be employed. The choice of mode dictates whether your encryption is robust or fatally flawed.

1. Electronic Codebook (ECB) — Fatally Insecure

In ECB mode, every 16-byte block is encrypted independently with the key. Identical plaintext blocks produce identical ciphertext blocks.

⚠️ The ECB Penguin Problem: Encrypting a bitmap image with ECB preserves the visual contours and structure of the image in the ciphertext. Never use ECB in production.

2. Cipher Block Chaining (CBC) — Legacy Malleability

In CBC mode, each plaintext block is XORed with the preceding ciphertext block before encryption.

Requires an Initialization Vector (IV) for the first block.
Requires padding (PKCS#7) to round the message up to an exact multiple of 16 bytes.
Vulnerability: CBC only provides confidentiality, not integrity. Without a secondary MAC (Message Authentication Code), CBC is susceptible to bit-flipping attacks and padding oracle attacks (such as POODLE).

3. Galois/Counter Mode (GCM) — The Gold Standard AEAD

AES-GCM combines counter-mode encryption with universal hashing over a Galois field $\text{GF}(2^{128})$.

AEAD (Authenticated Encryption with Associated Data): Simultaneously encrypts the payload and computes a 128-bit authentication tag (GMAC).
Tamper Resistance: If an attacker modifies even a single bit of the ciphertext or IV, decryption fails with an authentication error before any decrypted data is returned.
No Padding Needed: Operates as a stream cipher over counter increments; plaintexts of arbitrary byte lengths are encrypted without padding.
High Performance: Allows full pipelining and hardware acceleration via CPU instructions like Intel AES-NI and ARMv8 Cryptography.

The Nonce/IV Mandate: Why 96-Bit IV Uniqueness Is Absolute

In AES-GCM, the Initialization Vector (IV), often referred to as a nonce (number used once), initializes the counter function.

Counter Block 1 = IV (96 bits) || 0x00000001 (32 bits)
Counter Block 2 = IV (96 bits) || 0x00000002 (32 bits)

The Catastrophic “Two-Time Pad” Failure

If the same key and IV pair is reused across two different plaintexts ($P_1$ and $P_2$):

$$C_1 = P_1 \oplus \text{Keystream}$$

$$C_2 = P_2 \oplus \text{Keystream}$$

$$C_1 \oplus C_2 = P_1 \oplus P_2$$

An eavesdropper XORs the two ciphertexts to cancel out the keystream entirely, revealing the direct XOR of the plaintexts. Furthermore, the Galois hash key $H$ can be recovered mathematically, allowing the attacker to forge valid authentication tags.

Standard Operating Rules for IVs:

Never reuse an IV with the same key.
IVs are not secret: The IV is prepended in the clear to the ciphertext (e.g. [12-byte IV] + [Ciphertext] + [16-byte Tag]).
Always use CSPRNG: In web applications, generate IVs strictly with window.crypto.getRandomValues(new Uint8Array(12)).

Architectural Comparison of AES Modes

Security & Performance Dimension	AES-GCM (Recommended)	AES-CBC	AES-ECB (Broken)
Cipher Classification	AEAD (Authenticated)	Confidentiality Only	Raw Block Cipher
Authentication / Integrity	✅ Built-in 128-bit GMAC	❌ None (Requires HMAC)	❌ None
Padding Oracle Vulnerability	Immune (No padding used)	Vulnerable to padding oracles	Not applicable
Bit-Flipping Malleability	Detected & rejected immediately	Vulnerable without HMAC	Vulnerable
Parallel Processing	Fully parallelizable (SIMD)	Sequential encryption only	Parallelizable
Standard IV Length	96 bits (12 bytes)	128 bits (16 bytes)	No IV used
Standard Adoption	TLS 1.3, IPsec, WebCrypto, SSH	Legacy TLS, OpenVPN	Strictly prohibited

Client-Side Web Crypto API Implementation

Modern web browsers feature hardware-accelerated, cryptographically secure primitives via the W3C Web Cryptography API (crypto.subtle).

Here is the standard implementation for AES-GCM encryption and decryption:

// 1. Generate a Cryptographically Secure 256-bit Key
async function generateAesKey() {
 return await window.crypto.subtle.generateKey(
 { name: "AES-GCM", length: 256 },
 true,
 ["encrypt", "decrypt"]
 );
}

// 2. Encrypt UTF-8 Plaintext with AES-GCM
async function encryptAesGcm(plaintext, key) {
 const ec = new TextEncoder();
 // Generate a fresh, unique 96-bit (12-byte) IV for every encryption operation
 const iv = window.crypto.getRandomValues(new Uint8Array(12));

 const ciphertextWithTag = await window.crypto.subtle.encrypt(
 { name: "AES-GCM", iv: iv, tagLength: 128 },
 key,
 ec.encode(plaintext)
 );

 // Pack IV + Ciphertext + Tag into a single buffer for transmission
 const combined = new Uint8Array(iv.length + ciphertextWithTag.byteLength);
 combined.set(iv, 0);
 combined.set(new Uint8Array(ciphertextWithTag), iv.length);

 // Return as Base64 string
 return btoa(String.fromCharCode(...combined));
}

// 3. Decrypt and Verify Integrity
async function decryptAesGcm(base64Payload, key) {
 const binaryString = atob(base64Payload);
 const combined = Uint8Array.from(binaryString, c => c.charCodeAt(0));

 // Extract 12-byte IV and Ciphertext
 const iv = combined.slice(0, 12);
 const data = combined.slice(12);

 // Decryption throws an error if authentication tag does not match
 const decrypted = await window.crypto.subtle.decrypt(
 { name: "AES-GCM", iv: iv, tagLength: 128 },
 key,
 data
 );

 return new TextDecoder().decode(decrypted);
}

Step-by-Step: Encrypting Data in Toolbox

Open the Tool: Visit the .
Select Mode: Choose AES-GCM (Authenticated) for state-of-the-art security, or AES-CBC for legacy compatibility.
Set Key Size: Choose 256-bit for maximum cryptographic resilience.
Enter Plaintext & Secret Key: Input your text and provide a passphrase, or click Generate Secure Key to obtain a high-entropy hex key.
Client-Side Execution: The tool uses your browser’s hardware-accelerated crypto.subtle engine. Zero plaintext or keys ever touch any remote server.
Copy Encrypted Ciphertext: Retrieve the resulting Base64-encoded bundle containing the IV, ciphertext, and authentication tag.

Interactive Workbench LIVE

AES-256-GCM Authenticated Encryption: How to Secure Data in the Browser

Open Fullscreen ↗

Encrypt and decrypt confidential text using AES-GCM or AES-CBC directly in your browser with hardware-accelerated Web Crypto API.

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

FAQ

Frequently Asked Questions

Why is AES-GCM considered superior to AES-CBC for web applications? ▼

AES-GCM is an Authenticated Encryption with Associated Data (AEAD) cipher mode. Unlike AES-CBC, which only provides confidentiality and is vulnerable to padding oracle attacks unless paired with a separate HMAC, AES-GCM simultaneously provides confidentiality and cryptographic integrity through a 128-bit authentication tag (GMAC). Any tampering with the ciphertext causes decryption to fail immediately.

Why is reusing an Initialization Vector (IV) catastrophic in AES-GCM? ▼

In Galois/Counter Mode, the keystream is generated by encrypting incrementing counter blocks derived from the IV and key. If the same (Key, IV) pair is used to encrypt two different plaintexts, an attacker can XOR the ciphertexts to eliminate the keystream and uncover the XOR of the plaintexts, completely destroying confidentiality and enabling forgery of the authentication tag.

What is the recommended IV length for AES-GCM? ▼

The NIST SP 800-38D specification strongly recommends an Initialization Vector length of exactly 96 bits (12 bytes). A 96-bit IV is used directly as the initial counter block without undergoing additional GHASH processing, maximizing both performance and cryptographic security.

Is client-side browser encryption secure against server eavesdropping? ▼

Yes. When encryption executes inside the browser using the W3C Web Crypto API (crypto.subtle), plaintext data is transformed into ciphertext in local machine memory before any network transmission occurs. As long as keys are derived and held client-side and the serving domain has strict HTTPS and Content Security Policy (CSP), zero-knowledge confidentiality is preserved.

How to Generate SHA-256 and MD5 Hashes Online (Securely in Browser)

Fri, 04 Sep 2026 00:00:00 +0000

Free In-Browser Tool TOOLBOX UTILITY

Cryptographic Hash Generator

Generate instant SHA-256, MD5, and SHA-512 hashes with uppercase/lowercase toggles and binary file checksum support.

Generate SHA-256 Hash Now →

What Is a Cryptographic Hash Function?

A cryptographic hash function is a mathematical algorithm that transforms an arbitrary block of input data into a fixed-size bit string (a digest or checksum).

Every secure cryptographic hash possesses four essential properties:

Deterministic: The same input always produces the exact same hash.
Quick Computation: The digest can be computed rapidly for any data stream.
Pre-Image Resistance (One-Way): Given a hash $H$, it is computationally infeasible to find the original message $M$ such that $\text{hash}(M) = H$.
The Avalanche Effect: Modifying a single character or bit in the input radically alters the resulting digest.

Algorithm Comparison: MD5 vs SHA-1 vs SHA-256 vs SHA-512

Algorithm	Digest Size	Collision Resistance	Status	Primary Modern Use Case
MD5 (RFC 1321)	128 bits (32 hex)	❌ Broken ($2^{16}$ operations)	Insecure for Crypto	Legacy file integrity checksums
SHA-1 (FIPS 180-1)	160 bits (40 hex)	❌ Broken (SHAttered in 2017)	Deprecated	Git commit object identification
SHA-256 (FIPS 180-4)	256 bits (64 hex)	✅ Unbroken ($2^{128}$ complexity)	Gold Standard	TLS certificates, Bitcoin, file verification
SHA-512 (FIPS 180-4)	512 bits (128 hex)	✅ Unbroken ($2^{256}$ complexity)	Maximum Security	High-security government & banking applications

Why You Should Never Hash Passwords with Plain SHA-256

While SHA-256 is ideal for verifying file integrity and code signatures, it is dangerous to hash passwords directly with plain SHA-256 or MD5.

Modern GPUs can compute over 10 billion SHA-256 hashes per second. Attackers with precomputed rainbow tables can crack unsalted SHA-256 passwords in seconds. For password storage, always use slow, memory-hard key derivation functions like Argon2id, bcrypt, or PBKDF2.

Client-Side Hashing with the Web Crypto API

Modern web browsers support hardware-accelerated cryptographic operations natively via window.crypto.subtle:

async function calculateSHA256(message) {
 const encoder = new TextEncoder();
 const data = encoder.encode(message);
 const hashBuffer = await crypto.subtle.digest('SHA-256', data);
 const hashArray = Array.from(new Uint8Array(hashBuffer));
 return hashArray.map(b => b.toString(16).padStart(2, '0')).join('');
}

Because execution happens within your device’s browser sandbox, your sensitive data is completely protected from interception. Test it right now with our .

Interactive Workbench LIVE

Generate SHA-256 and MD5 Hashes Online (Securely in Browser)

Open Fullscreen ↗

Generate instant SHA-256, MD5, and SHA-512 hashes with uppercase/lowercase toggles and binary file checksum support.

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

FAQ

Frequently Asked Questions

Why is MD5 no longer considered cryptographically secure? ▼

MD5 is vulnerable to collision attacks, where two distinct input strings produce the exact same 128-bit hash digest. In 2008, security researchers demonstrated forging rogue SSL certificates using MD5 collisions. However, MD5 is still widely used as a fast, non-cryptographic checksum for file transfer verification.

Can a SHA-256 hash be decrypted back to its original input? ▼

No. Cryptographic hash functions are strictly one-way mathematical algorithms, not encryption. You cannot reverse or decrypt a hash digest. The only way to find the original input is via brute-force dictionary attacks (rainbow tables).

Does hashing files in Toolbox upload my data to a server? ▼

No. The hashing engine uses the browser's native Web Cryptography API (crypto.subtle.digest) to compute digests locally on your CPU/GPU. Zero bytes of your file or text are transmitted over the internet.