RSA Encrypt & Decrypt Online — RSA-OAEP with PEM or JWK Keys

RSA-OAEP (RFC 8017) uses a padding scheme with a security proof under standard assumptions, and it's much harder to attack than the older PKCS#1 v1.5 encryption padding, which is vulnerable to Bleichenbacher-style attacks against many real implementations. All modern libraries default to OAEP for encryption. Only fall back to PKCS#1 v1.5 when interoperating with strictly legacy systems — and in that case, don't use this tool, use a library where you can audit constant-time behavior.

For RSA-OAEP with a k-byte modulus and an h-byte hash: k − 2·h − 2 bytes. So RSA-2048 (256 B) with OAEP-SHA-256 (32 B) fits at most 190 bytes. RSA is not meant for bulk encryption — the standard pattern is 'hybrid encryption': generate a random AES key, encrypt your data with AES-GCM, then encrypt just the 32-byte AES key with RSA-OAEP.

Yes. RSA-OAEP internally uses a hash function; encryption and decryption MUST use the same hash (and the same MGF1 hash, which WebCrypto ties to the main hash). If your ciphertext was produced with SHA-1 and you try to decrypt with SHA-256, decryption fails with a padding error. When someone else produced the ciphertext, ask them which hash they used.

Both PEM and JWK. For PEM, the private key must be PKCS#8 (-----BEGIN PRIVATE KEY-----) and the public key must be SPKI (-----BEGIN PUBLIC KEY-----). For JWK, paste the JSON object as-is (with kty="RSA"). If your key is in a legacy format, convert with: openssl pkcs8 -topk8 -nocrypt -in old.pem -out new.pem.

No. All operations run in your browser via crypto.subtle. You can verify with DevTools Network panel — clicking Decrypt produces zero network traffic. That said, don't paste production private keys into unfamiliar tools; use this for development, testing, and one-off decryptions.