A 2048-bit RSA key does not encrypt 256 bytes of useful plaintext. With OAEP-SHA256, the practical ceiling is 190 bytes. The rest of the block is consumed by padding that makes textbook RSA safe enough for real encryption. That small arithmetic detail explains why long-message tools must split input, why ciphertext grows in 256-byte jumps, and why RSA is normally used to wrap a symmetric key rather than carry a document. The RSA Encrypt / Decrypt tool makes those boundaries visible instead of hiding them behind an “encrypt” button.
The 190-byte limit hiding inside a 2048-bit key
RSA works on integers smaller than its modulus. For a 2048-bit key, the modulus occupies 256 bytes. OAEP does not hand all 256 bytes to the message. Its encoded block reserves space for a seed, a label hash, a delimiter, and the masking structure that randomizes each encryption.
The maximum plaintext length is:
k - 2 x hLen - 2
Here, k is the modulus length in bytes and hLen is the digest length. With a 2048-bit key and SHA-256, the calculation is 256 minus 64 minus 2, leaving 190 bytes. Switch to SHA-1 and its 20-byte digest leaves 214 bytes, but the extra room is a poor reason to choose a legacy hash for new work. The tool defaults to SHA-256 and labels it as recommended.
This limit applies to bytes, not visible characters. A 190-character ASCII message fits in one block. A message containing multibyte UTF-8 characters may cross the boundary sooner. That distinction matters when a UI reports character counts while the cryptographic primitive receives bytes.
Why OAEP earns the space it consumes
Raw RSA is deterministic and algebraically structured. Encrypting the same small message under the same key would otherwise reveal repeatable relationships. OAEP, short for Optimal Asymmetric Encryption Padding, mixes the plaintext with fresh randomness and hash-derived masks before the RSA operation. Two encryptions of the same message should produce different ciphertext.
The lost payload capacity is therefore not waste. It buys probabilistic encryption and removes the obvious patterns that make textbook RSA unsuitable for application data. OAEP also binds its decoding checks to the selected hash. Encryption and decryption must agree on SHA-256 or SHA-1; a mismatch fails rather than producing a plausible but incorrect message.
The tool intentionally omits PKCS#1 v1.5 decryption. That older padding scheme has a long history of Bleichenbacher-style oracle attacks when applications reveal whether padding was valid. Modern Node.js disables the risky private-decrypt path. A security tool is more useful when it refuses an unsafe compatibility option than when it presents every historical mode as equivalent.
Chunking turns one message into many RSA operations
The implementation inspects the key to obtain its modulus length, computes the OAEP maximum, converts the message to UTF-8 bytes, and slices the buffer at that boundary. Each slice is encrypted independently. The resulting fixed-size ciphertext blocks are concatenated.
For a 2048-bit key with OAEP-SHA256:
- 1 to 190 plaintext bytes become one 256-byte ciphertext block.
- 191 to 380 plaintext bytes become two blocks, or 512 ciphertext bytes.
- 381 to 570 plaintext bytes become three blocks, or 768 ciphertext bytes.
Decryption reverses the process. It splits ciphertext at the modulus boundary, decrypts each 256-byte block with the private key, then concatenates the recovered plaintext chunks. The interactive tool reports the key size and block count, so this step function is visible in the result rather than inferred from a long hex string.
Chunking is convenient for a demonstration and for modest payloads. It is not a complete message protocol. The concatenation has no independent version marker, message identifier, sequence number, or whole-message authentication tag. An application designing a transport format must define those properties rather than treating concatenated RSA blocks as a ready-made envelope.
Ciphertext encoding changes length, not security
The tool can render ciphertext as hexadecimal or Base64. Both represent the same encrypted bytes. Hex uses two characters per byte, so one 256-byte RSA block occupies 512 hex characters. Base64 uses roughly four characters for every three bytes, so the same block occupies 344 characters including padding.
Encoding does not strengthen or weaken OAEP. It affects storage, copy-and-paste ergonomics, and interoperability. Hex is easy to inspect and compare in a debugger. Base64 is more compact and common in JSON, PEM-adjacent workflows, and text protocols. Whichever representation you choose, decryption must decode it back to the exact ciphertext bytes before applying the private key.
A useful diagnostic is divisibility. After decoding, the ciphertext byte length must be an exact multiple of the modulus size. A 510-byte payload cannot be two intact 2048-bit RSA blocks. It was truncated, decoded under the wrong representation, or produced by a different key size.
A concrete one-block experiment
The manifest includes a real example named “Encrypt a short message with an RSA public key (OAEP-SHA256).” Its plaintext is Hello, RSA!, encoded as UTF-8, with a 2048-bit public key and hexadecimal output. The result is one 256-byte block displayed with block metadata.
Run that input twice and the hex should differ because OAEP draws fresh randomness for every encryption. Decrypt either result with the matching private key, the same OAEP hash, and the correct encoding, and both recover the same plaintext. This is a compact test of three properties at once: randomized ciphertext, deterministic recovery, and strict parameter agreement.
You can reproduce the experiment in the RSA Encrypt / Decrypt tool. Keep real production private keys out of demos even when processing is local; use a disposable test pair and delete copied ciphertext when the exercise is done.
Public keys travel; private keys stay controlled
The public key is the encryption input. It is designed to be distributed. The matching private key is the decryption input and may be passphrase-protected; the tool accepts a passphrase when needed. A successful round trip proves that the key pair and OAEP parameters match, but it does not prove who supplied the public key.
That identity question is separate and essential. A substituted public key lets an attacker receive ciphertext that only the attacker can decrypt. Certificates, fingerprints, signed key directories, or an authenticated channel establish trust in the key. Encryption without key authentication can protect data perfectly for the wrong recipient.
Local processing narrows exposure because keys and plaintext are handled by the running tool rather than intentionally sent to a remote cryptographic service. It does not erase endpoint risks: browser extensions, clipboard managers, screenshots, crash logs, and a compromised machine can still capture sensitive material. Treat the browser as an endpoint, not a magic isolation boundary.
Why production systems use hybrid encryption
Chunked RSA demonstrates the primitive clearly, but production systems usually generate a random symmetric key, encrypt the actual payload with an authenticated cipher such as AES-GCM or ChaCha20-Poly1305, and use RSA-OAEP only to encrypt that short key. This is hybrid encryption.
The design solves several problems at once. Symmetric encryption handles large data efficiently. The authentication tag detects tampering across the whole message. RSA carries a small, fixed-size secret that stays comfortably below the OAEP limit. A structured envelope can then record the algorithm, nonce, wrapped key, ciphertext, tag, and version.
RSA-OAEP still has a valuable job; it is simply a narrow one. Use it to protect compact secrets or to learn public-key mechanics. Use an established hybrid format or protocol for files, streams, API payloads, and persistent records. The distinction prevents a working classroom demo from quietly becoming an underspecified production cryptosystem.
A practical checklist before decrypting
Before blaming the key, verify the inputs in order:
- Confirm the ciphertext representation is Hex or Base64 as selected.
- Decode it and check that its byte length is a multiple of the RSA modulus size.
- Use the private key paired with the public key that encrypted the message.
- Match the OAEP hash exactly; SHA-256 ciphertext needs SHA-256 decryption.
- Supply the correct passphrase if the private key itself is encrypted.
- Reject damaged, partial, or context-free concatenated blocks rather than guessing.
Error messages are part of the security boundary. Do not expose detailed padding failures to remote callers; uniform failure responses reduce oracle risk. In a local learning tool, specific validation errors help diagnose malformed PEM, missing fields, zero-length ciphertext, and encoding mistakes without turning a network endpoint into a probe.
The boundary determines the design
In the end, RSA becomes practical when its boundary drives the architecture: 256 modulus bytes, 32 hash bytes, 190 plaintext bytes, then another full 256-byte ciphertext block. OAEP removes unsafe determinism. Chunking shows the cost. Hybrid encryption fixes the design for large or authenticated data. Test those mechanics with disposable keys, then build production envelopes with an established protocol. The next question is not “Can RSA carry this file?” but “What compact secret should RSA wrap while an authenticated cipher protects everything else?” Explore more focused utilities at elysiatools.com.
