Introduction
Need to sign a message with RSA-PSS or ECDSA and verify it with the public key, all in your browser? This tool uses the Web Crypto API to generate key pairs, sign messages, and verify signatures across four algorithms: RSA-PSS (2048-bit), ECDSA P-256, ECDSA P-384, and ECDSA P-521. Ed25519 support is detected at runtime and offered when the browser supports it. Keys are exported in JWK format so you can share the public key and verify signatures anywhere. No private key ever leaves your device.
What this tool does
- Generate key pairs for RSA-PSS (2048-bit, SHA-256), ECDSA P-256 (SHA-256), ECDSA P-384 (SHA-384), or ECDSA P-521 (SHA-512) using the native Web Crypto API
- Sign arbitrary text messages with the private key, producing signatures in hex or Base64 encoding
- Verify a signature against the original message and a public key provided as JWK JSON, returning a clear valid or invalid result
- Export both public and private keys in JWK (JSON Web Key) format for portability across systems
- Detect Ed25519 (EdDSA) support at runtime via a feature probe, and surface it only when the browser implements it (Chrome 113+, recent Firefox)
- Run entirely client-side: key generation, signing, and verification all happen in the browser through window.crypto.subtle
How this tool works
The tool calls the Web Crypto API (`crypto.subtle`) for every cryptographic operation. Key generation uses `crypto.subtle.generateKey` with algorithm-specific parameters: RSA-PSS requires a modulus length of 2048 bits and a public exponent of 65537, while ECDSA takes a named curve (P-256, P-384, or P-521). The resulting `CryptoKeyPair` is exported to JWK format via `crypto.subtle.exportKey` so both keys are visible as JSON objects.
Signing calls `crypto.subtle.sign` with the private key and the UTF-8-encoded message. RSA-PSS uses a salt length equal to the hash length (32 bytes for SHA-256). ECDSA produces DER-encoded ASN.1 signatures (a SEQUENCE of two INTEGERs, r and s). The raw signature bytes are then encoded as hex or Base64 for display.
Verification works in reverse. The tool parses the public key from JWK JSON using `crypto.subtle.importKey`, decodes the signature from hex or Base64, and calls `crypto.subtle.verify` with the public key, signature, and message. The result is a boolean. A green badge means the signature matches the message and key. A red badge means something was altered.
The tool probes for Ed25519 support on mount by attempting `crypto.subtle.generateKey('Ed25519', ...)`. If the promise resolves, Ed25519 appears as an option. If it rejects, the option is grayed out with a note. This matches the reality of browser support in 2026: Chrome and recent Firefox support Ed25519, but some older browsers do not.
How digital signatures work (FIPS 186-5, RFC 8032)
Digital signatures provide three guarantees: authenticity (the signer holds the private key), integrity (the message was not modified), and non-repudiation (the signer cannot deny signing). The standards are FIPS 186-5 for ECDSA and RSA-PSS, RFC 8032 for Ed25519, and RFC 3447 for PKCS#1 (the basis for RSA-PSS).
RSA-PSS (Probabilistic Signature Scheme) is the modern RSA signature standard. It applies a salt to the message before signing, making each signature different even for the same message and key. The salt length is typically set to the hash output length (32 bytes for SHA-256). PSS is specified in RFC 8017 and is preferred over the older PKCS#1 v1.5 scheme because it has a security proof.
ECDSA operates on elliptic curves over finite fields. The private key is a scalar d, and the public key is the point Q = d * G. Signing produces a pair (r, s) derived from a nonce k and the message hash. Verification checks a mathematical relationship between r, s, the message hash, and Q. See the ECDSA Signature tool for a deeper explanation of the math.
Ed25519 is an Edwards-curve signature scheme specified in RFC 8032. It uses Curve25519, produces fixed 64-byte signatures, and is deterministic (no nonce to misuse). It is faster than ECDSA and RSA-PSS, and is the default in SSH, Signal, and the age encryption tool. The Web Crypto API specification added Ed25519 support, though browser adoption took several years.
All three algorithms are vulnerable to quantum attacks. Shor's algorithm breaks both integer factorization (RSA) and the elliptic curve discrete logarithm problem (ECDSA, Ed25519). NIST's post-quantum standards ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) are being deployed as replacements. See the Post-Quantum Playground for an overview.
How to use this tool
- Select an algorithm: RSA-PSS (2048-bit), ECDSA P-256, ECDSA P-384, ECDSA P-521, or Ed25519 (if your browser supports it)
- Choose a mode: Sign (generate keys and sign a message) or Verify (check a signature against a public key)
- In Sign mode, click Generate Key Pair. The tool creates the keys via the Web Crypto API and displays them as JWK JSON
- Type or paste your message in the input field. The message is encoded as UTF-8 before signing
- Click Sign Message. The tool hashes the message with the algorithm-appropriate hash function and produces the signature in hex or Base64
- Copy the public key JWK and the signature. Share them with anyone who needs to verify your message
- In Verify mode, paste the original message, the signature (in the matching encoding), and the public key JWK. Click Verify Signature
- The badge shows VALID (green) or INVALID (red). Try changing one character in the message to see verification fail
Real-world examples
Signing and verifying with ECDSA P-256
Select ECDSA P-256 and Sign mode. Click Generate Key Pair. Type `Invoice #1042, amount $5000`. Click Sign. The tool hashes the message with SHA-256, signs it with the private key, and outputs a DER-encoded signature (typically 70-72 bytes) in hex. Copy the public key JWK. Switch to Verify mode, paste the same message, the signature, and the public key. Click Verify: the badge shows VALID. Now change the amount to $6000 and click Verify again: the badge shows INVALID. The signature is bound to the exact message bytes.
RSA-PSS with salt-based randomization
Select RSA-PSS (2048-bit) and generate a key pair. Sign the message `Hello RSA-PSS` twice. Both signatures are different because PSS applies a random salt before signing. This is a security feature: an attacker cannot link signatures to detect repeated messages. Despite different signatures, both verify against the same public key and message. This differs from deterministic schemes like Ed25519, where the same message and key always produce the same signature.
Verifying a tampered signature
Sign a message with ECDSA P-384 and copy the signature hex. Flip one hex digit (e.g. change the first character from `3` to `4`). Paste the modified signature in Verify mode with the original message and public key. The result is INVALID. ECDSA verification computes a point R' from the signature components and checks that its x-coordinate matches r. Any change to r or s produces a different R', so the check fails. This is the integrity guarantee: a valid signature proves the message was not modified after signing.
Ed25519 on a supported browser
If your browser supports Ed25519 (Chrome 113+, recent Firefox), select Ed25519 and generate a key pair. The public key is a 32-byte point and the private key is a 32-byte scalar, both shown as JWK with base64url-encoded fields. Sign the message `Test Ed25519`. The signature is exactly 64 bytes, fixed length, regardless of message size. Sign the same message again: the signature is identical because Ed25519 is deterministic. This is why Ed25519 is preferred for systems that need reproducible signatures.
Sharing the public key for third-party verification
Sign a message with RSA-PSS and copy the public key JWK JSON. Send the message, signature, and public key to a colleague. They can paste all three into the Verify mode of this tool (or any Web Crypto API consumer) and confirm authenticity. The private key never leaves your device. This is how JWT, TLS certificate pinning, and software distribution signing work: the signer holds the private key, and verifiers only need the public key.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| RSA-PSS 2048 | 2048-bit modulus, SHA-256, ~112-bit security | Legacy TLS, X.509 certificates, code signing |
| ECDSA P-256 | 256-bit curve, SHA-256, ~128-bit security | TLS 1.3, JWT (ES256), Apple Secure Enclave |
| ECDSA P-384 | 384-bit curve, SHA-384, ~192-bit security | High-assurance TLS, government systems |
| ECDSA P-521 | 521-bit curve, SHA-512, ~256-bit security | Maximum security NIST curve, rare in practice |
| Ed25519 | 255-bit Edwards curve, 64-byte signatures, ~128-bit security | SSH, Signal, age, modern systems (browser support varies) |
| ML-DSA (Dilithium) | Lattice-based, post-quantum, FIPS 204 | Future post-quantum signatures (see Post-Quantum Playground) |
Limitations or considerations
This tool signs text messages only. For binary data or files, use a command-line tool like `openssl dgst -sign` or a library. The same algorithms apply, but the tool's UI is designed for text input.
The Web Crypto API does not guarantee deterministic signatures for RSA-PSS or ECDSA. RSA-PSS uses a random salt by design. ECDSA in Web Crypto may use a random nonce, so signing the same message twice on P-256 may produce different signatures. Both signatures verify correctly, but you cannot use them as unique identifiers. Ed25519 is deterministic by specification.
Ed25519 support depends on the browser. Chrome 113+ and recent Firefox support it. Safari and older browsers may not. The tool probes for support and disables the option if unavailable. For Ed25519 on unsupported browsers, use the `@noble/curves` library or libsodium.
None of these algorithms are post-quantum secure. Shor's algorithm on a sufficiently large quantum computer breaks RSA, ECDSA, and Ed25519. NIST's ML-DSA (FIPS 204) is the post-quantum replacement for digital signatures. See the Post-Quantum Playground for details.
The tool does not support RSA-PKCS1-v1.5 signatures, which are deprecated in favor of PSS. It also does not support Ed448 or RSA-PSS with key lengths other than 2048 bits. For those, use OpenSSL or a dedicated library.
Frequently asked questions
What is the difference between RSA-PSS and RSA-PKCS1 v1.5?
RSA-PSS applies a random salt to the message before signing, making each signature unique even for the same message. It has a security proof in the random oracle model. RSA-PKCS1 v1.5 is the older scheme (RFC 3447) and does not use a salt. PSS is preferred for new applications and is required in TLS 1.3 for RSA signatures. This tool uses PSS exclusively.
Why does the same message produce different signatures with RSA-PSS?
RSA-PSS injects a random salt (32 bytes for SHA-256) into the padding before signing. Each signing operation uses a fresh salt, so the signature changes even if the message and key are identical. This prevents an attacker from linking signatures. Verification works because the salt is embedded in the signature and recovered during the verification process.
Is Ed25519 better than ECDSA?
For most new applications, yes. Ed25519 produces fixed 64-byte signatures (vs 70-72 bytes for ECDSA P-256), is deterministic (no nonce misuse risk), and is faster. It is the default in SSH, Signal, and age. The main drawback is browser support: the Web Crypto API added Ed25519 relatively recently, and not all browsers implement it. ECDSA P-256 has broader support and is the standard in TLS and JWT.
Can someone derive my private key from the public key?
No, not on a classical computer. The security of RSA relies on the difficulty of factoring large integers. The security of ECDSA and Ed25519 relies on the elliptic curve discrete logarithm problem. Both are computationally infeasible for properly sized keys. However, a sufficiently powerful quantum computer running Shor's algorithm could break all three. Post-quantum algorithms like ML-DSA (FIPS 204) are being deployed to address this.
What is JWK and why does the tool use it?
JWK (JSON Web Key) is a JSON-based format for representing cryptographic keys, specified in RFC 7517. It is the native export format for the Web Crypto API. A public key JWK contains the key type, curve (for EC), and coordinates. You can share the public key JWK freely. The private key JWK contains the secret scalar and should never be shared. To convert between JWK, PEM, and DER formats, use the JWK Converter.
How is this tool different from the ECDSA Signature tool?
The ECDSA Signature tool focuses on ECDSA with secp256k1 support (the Bitcoin curve) and RFC 6979 deterministic nonces via the @noble/curves library. This tool uses the Web Crypto API exclusively, supports RSA-PSS and Ed25519 in addition to ECDSA, and includes P-521. Use the ECDSA Signature tool for secp256k1 and deterministic nonce demonstrations. Use this tool for broader algorithm coverage and JWK-based key exchange.
Conclusion
Digital signatures are the foundation of authentication on the internet, from TLS certificates to JWT tokens to software distribution. This tool covers RSA-PSS, ECDSA (P-256, P-384, P-521), and Ed25519 through the Web Crypto API, with runtime detection for Ed25519 browser support. For ECDSA with secp256k1 and deterministic nonces, see the ECDSA Signature tool. For RSA key generation and encryption, see the RSA Encrypt / Decrypt tool. To convert between key formats, see the JWK Converter.