Security Tools New Tool

Free Online RSA Encrypt and Decrypt with OAEP, Signing and Verifying

Encrypt or decrypt a short message with RSA-OAEP, or sign and verify one with PKCS1 v1.5 or RSA-PSS. Paste a public or private key as PEM or as JWK, pick the hash, and the page tells you the OAEP size limit before you hit it. Nothing is uploaded.

Free Forever Nothing Uploaded OAEP And Signatures Nothing Uploaded

Free Online RSA Encrypt and Decrypt with OAEP, Signing and Verifying

Advertisement Slot (Top Banner) Google AdSense Unit • Responsive Banner

RSA Encrypt & Decrypt Everything happens in this tab. Nothing you paste is sent anywhere.

Your message

Result

Job

Signature

Key

Buy Us A Coffee

Enjoying WizTools123? Help keep our server infrastructure 100% free and open for everyone.

Buy Us A Coffee

Sponsored Content (Below Tool) Google AdSense Placement

Why RSA Cannot Encrypt a Long Message

And what everybody does instead.

The first thing people hit with RSA is not a padding error or a key problem. It is that a 2048 bit key refuses anything longer than about 190 bytes. That is not a limitation of this page, it is what RSA is: one operation on one number smaller than the modulus.

The limit is the key size minus the padding. With OAEP the message has to fit in the modulus with room for two hashes and two bytes, so the ceiling is the key length in bytes minus twice the hash length minus two. A 2048 bit key with SHA-256 gives 190 bytes. Choosing SHA-512 on the same key drops it to 126. This page works that out for whatever you have pasted and shows it next to the length of your message.

Real systems encrypt a key with RSA, not the data. The pattern is called hybrid or envelope encryption: generate a random AES key, encrypt the data with AES, then encrypt that one small AES key with RSA. The RSA step is always comfortably within the limit because an AES key is 16 or 32 bytes, and the data can be any size at all. That is how TLS, S/MIME, PGP and every file format that says RSA actually work.

Splitting a message into blocks is not the answer. It is the obvious workaround and it is a bad one: identical blocks encrypt to identical ciphertext, the result is many times larger, and nothing authenticates the order of the pieces. If you find a tool that encrypts a megabyte with RSA alone, that is what it is doing. This page refuses instead, and tells you the figure.

Signing has no such limit, because the hash is what gets signed. A signature is made over a fixed length digest, so a one byte message and a one gigabyte message produce the same amount of work for the key. That is why the signing side of this page accepts any length while the encryption side does not.

How to Encrypt a Message with RSA

A few steps, and nothing is uploaded.

Choose the job Encrypting and verifying need a public key. Decrypting and signing need the private one. The label above the key box changes to say which, so there is no guessing.

Paste the key as PEM or JWK A PEM beginning BEGIN PUBLIC KEY or BEGIN PRIVATE KEY, or the JSON of a JWK. A PKCS1 PEM, the kind that says BEGIN RSA PUBLIC KEY, gets a clear message rather than a silent failure.

Match the hash OAEP and the signature schemes both bind a hash, and both sides have to agree. If the other end used SHA-256, choose SHA-256 here, otherwise a correct key will still fail.

Watch the size figure before encrypting The page shows the OAEP ceiling for your key and hash, and how long your message is. If it does not fit, encrypt a random AES key with RSA and the data with AES instead.

What to Know About RSA

Starting with why the message has to be short.

RSA cannot encrypt anything much longer than a couple of hundred bytes, and this page will not pretend otherwise. A 2048 bit key with SHA-256 tops out at 190 bytes, and a tool that appears to beat that is quietly splitting your message into blocks, which leaks repeated content and authenticates nothing. For real data, encrypt an AES key with RSA and the data with AES. The AES page on this site does the second half.

PKCS1 PEM keys are not readable here, because the browser cannot read them. Web Crypto imports exactly two binary shapes, SPKI for public keys and PKCS8 for private ones, which in PEM look like BEGIN PUBLIC KEY and BEGIN PRIVATE KEY. A key that says BEGIN RSA PUBLIC KEY or BEGIN RSA PRIVATE KEY is PKCS1 and needs one openssl command to convert. The page says so by name instead of failing with nothing.

A key is bound to one job and one hash, so mismatches look like broken keys. A key imported for OAEP cannot verify a signature, and a signature made over SHA-256 will not check against SHA-512 however correct the key is. Most reports of a key not working are one of these two, which is why the job and the hash are both on screen rather than assumed.

Nothing is remembered, and a private key pasted here should be a test key. There is no history and no saved setup on this page, deliberately. The arithmetic is Web Crypto and nothing is uploaded, but a private key that has passed through a clipboard and a browser tab is not a key you should still be protecting anything real with.

Key Features & Capabilities

What this tool does, and what it deliberately does not.

OAEP both ways Encrypt and decrypt with RSA-OAEP and SHA-256, SHA-384 or SHA-512.

Sign and verify PKCS1 v1.5 or RSA-PSS, with the signature as base64 and a plain verdict.

PEM or JWK Paste either. A PKCS1 PEM gets named and explained rather than silently refused.

The size limit shown The OAEP ceiling for your key and hash, next to the length of your message.

Honest verdicts A failed verify says so clearly, and a wrong key is distinguished from a wrong signature.

Nothing remembered No history and no saved setups. A pasted private key never reaches browser storage.

About RSA in a Browser

RSA does one thing: it turns a number smaller than the modulus into another number, one way with the public key and the other way with the private one. Everything built on it is arrangement around that single operation. Encryption pads the message into a number with OAEP, signing hashes the message first and pads the digest, and both of those padding schemes bind a hash that the other side has to match. This page exposes all four combinations because they share every input except the key.

The part worth knowing before you start is the size limit, so it is on screen rather than in an error. RSA-OAEP can carry the key length in bytes minus twice the hash length minus two, which is 190 bytes on a 2048 bit key with SHA-256 and 126 bytes if you switch to SHA-512. The page computes that from the key you actually pasted and shows it beside the length of your message, because the alternative is a failed operation and a guess about why.

The other common wall is the key format. Web Crypto imports SPKI and PKCS8, which are the PEMs that say BEGIN PUBLIC KEY and BEGIN PRIVATE KEY, and it has no idea what to do with PKCS1, the older BEGIN RSA PUBLIC KEY form that plenty of tools still emit. Rather than returning an unhelpful failure, the page recognises the header, names the format, and says what converts it. JWK is accepted too, since that is what a JWKS endpoint hands you.

What this page is for is the moment when two systems disagree: a signature that will not verify, a ciphertext that will not open, a key that one library accepts and another rejects. Having the job, the scheme, the hash and the key all visible at once is usually enough to find the mismatch in a minute. What it is not for is protecting real data, both because RSA alone cannot carry much of it and because a private key in a browser tab has already been somewhere you cannot audit.

Frequently Asked Questions

Key formats, padding, size limits and signatures.

Almost always because it is too long. RSA-OAEP can only carry the key length in bytes minus twice the hash length minus two, so a 2048 bit key with SHA-256 stops at 190 bytes. The page shows that figure and your message length side by side. For anything bigger, encrypt an AES key with RSA and the data with AES.

Check the first line. BEGIN PUBLIC KEY and BEGIN PRIVATE KEY are the formats the browser can import. BEGIN RSA PUBLIC KEY and BEGIN RSA PRIVATE KEY are PKCS1, which Web Crypto cannot read at all, and one openssl command converts them. A certificate is not a key either, though the certificate decoder on this site will pull the key out of one.

PSS if you get to choose, because its security argument is stronger and it adds a random salt, so signing the same message twice gives different signatures. PKCS1 v1.5 is still what most existing systems use, including RS256 in JWT, so it is here and it is the default. The verifier has to use the same one either way.

Because PSS salts the padding with random bytes, so each signature is different and all of them verify. PKCS1 v1.5 is deterministic and gives the same signature every time. If you are comparing two signatures for equality, that difference is why a PSS comparison fails while verification passes.

No. The import, the encryption and the signing all happen in the browser own cryptography, with no request made. There is also no history and no saved setup here, so nothing is written to browser storage either. Closing the tab is the whole of the cleanup.