RSA Keys Converter
Convert RSA keys online between PKCS#1, PKCS#8, SPKI, and encrypted PEM wrappers so the same key fits servers, libraries, and deployment handoffs.RSA Key Conversion
| Field | Value | Copy |
|---|---|---|
| {{ row[0] }} | {{ row[1] }} | |
| No RSA key details available. | ||
| Target | PEM header | Key material | Status | Handoff note | Copy |
|---|---|---|---|---|---|
| {{ row.target }} | {{ row.pemHeader }} | {{ row.keyMaterial }} | {{ row.status }} | {{ row.handoff }} | |
| No format readiness data available. | |||||
{{ outputText }}
| Check | Value | Copy |
|---|---|---|
| {{ row[0] }} | {{ row[1] }} |
Introduction
RSA keys are often rejected for packaging reasons rather than cryptographic ones. The same modulus and exponent can appear inside several PEM labels, and a server, library, certificate workflow, or hardware appliance may accept only one of them. A destination that asks for PRIVATE KEY can refuse RSA PRIVATE KEY even when both describe the same keypair.
That matters whenever an older RSA file has to move into a newer stack, a public key has to be extracted for distribution, or a private key has to be re-saved with passphrase protection. PKCS#1, PKCS#8, and SubjectPublicKeyInfo solve different packaging problems. Changing between them can alter the wrapper, the PEM label, and the presence of encryption around private material, but it does not generate a new RSA key.
A hard limit sits underneath every conversion choice. A private key contains the matching public component, so it can be re-expressed as either a private wrapper or a public wrapper. A public key contains only the public values, so it can never be turned back into a private key. That is why some conversions are possible in only one direction.
PEM text should not be judged by appearance alone. Line wrapping, header labels, and passphrase protection can make two files look different even though the decoded public key is unchanged. The reliable comparison point is the decoded key structure, not the exact line breaks on screen.
Private keys and passphrases stay sensitive throughout that process. Even when conversion happens entirely on one device, copied text, downloaded files, and the open browser session still deserve the same care as the original secret.
Technical Details:
RSA public key material is built from two numbers: the modulus n and the public exponent e. An RSA private key carries those public values plus the private exponent and other secret parameters needed for signing and decryption. Because the public part is embedded inside the private part, a private key can always supply the matching public key.
The wrapper formats sit above that math. PKCS#1 defines RSA-specific public and private key structures. PKCS#8 defines generic private-key containers that can hold RSA or other algorithms, in either clear PrivateKeyInfo form or encrypted EncryptedPrivateKeyInfo form. SubjectPublicKeyInfo, usually shortened to SPKI, is the generic public-key structure behind the PEM label PUBLIC KEY.
RFC 7468 covers the text armor around those structures. The header and footer lines tell a parser which kind of object to expect, while the base64 body carries DER-encoded ASN.1. PEM wrapping is presentation, not identity. If the same DER object is rewrapped at a different line length, the key has not changed.
| Wrapper | PEM label | Underlying structure | Contains | Buildable from public input |
|---|---|---|---|---|
| PKCS#1 private | RSA PRIVATE KEY |
RSAPrivateKey | Public values plus private values | No |
| PKCS#8 private | PRIVATE KEY |
PrivateKeyInfo | Algorithm identifier plus private key payload | No |
| PKCS#8 encrypted | ENCRYPTED PRIVATE KEY |
EncryptedPrivateKeyInfo | Encrypted PKCS#8 private-key container | No |
| SPKI public | PUBLIC KEY |
SubjectPublicKeyInfo | Algorithm identifier plus public key bit string | Yes |
| PKCS#1 public | RSA PUBLIC KEY |
RSAPublicKey | RSA modulus and public exponent | Yes |
Comparison values are only useful if they are anchored to decoded bytes rather than raw PEM text. A modulus digest answers the narrow question "is this the same RSA public number set?" A SPKI pin answers the broader question "is this the same public-key structure after DER encoding?" That makes SPKI pinning useful when a public key moves between certificate and application contexts.
| Comparison value | Derived from | Stable across PEM rewrap | Best use | Limit |
|---|---|---|---|---|
| Modulus SHA-256 digest | RSA modulus bytes only | Yes | Quick same-key check inside RSA-only work | RSA-specific and blind to the enclosing public-key wrapper |
| SPKI pin | DER-encoded SubjectPublicKeyInfo | Yes, as long as the public key is the same | Public-key comparison across certificate and application uses | Depends on the full public-key structure, not just header text |
Transformation Core
- Read the PEM boundary lines and decode the underlying ASN.1 object.
- If private material is present, recover the embedded public values so both private and public wrappers can be generated from the same source.
- Serialize the target structure: PKCS#1 for RSA-specific wrappers, PKCS#8 for generic private-key wrappers, or SubjectPublicKeyInfo for generic public-key wrappers.
- If passphrase protection is requested, encrypt the PKCS#8 private-key structure before PEM encoding. Otherwise write the clear private-key or public-key structure directly.
- Base64-wrap the DER bytes into PEM text and compare outputs by decoded digests rather than by body width or header text alone.
Everyday Use & Decision Guide:
Start with inspection, not with export. Paste or upload one PEM-encoded RSA key, leave Output format on Info only, and check whether the summary badges and Detected Input field match what you thought you had. That first pass catches the most common mistake: trusting a file name or ticket note instead of the actual wrapper in the PEM block.
Choose the next format by the destination's exact expectation.
- Use
PKCS#8 privatewhen software expectsPRIVATE KEYor a generic asymmetric-key loader. - Use
PKCS#1 privateonly when a legacy RSA-specific consumer still wantsRSA PRIVATE KEY. - Use
PKCS#8 encryptedwhen the same private key must be stored or handed off with passphrase protection. - Use
SPKI publicwhen a system wants a genericPUBLIC KEYfile. - Use
PKCS#1 publiconly when the destination explicitly asks forRSA PUBLIC KEY.
The PEM wrap control changes formatting, not cryptography. Leaving it at 64 is the safe default unless another parser insists on a different width. The more important branch is private versus public input. If Key Kind is Public, only public outputs are possible. If you need any private-key wrapper, the source must already be a private key.
Another easy misread is assuming an input passphrase automatically produces an encrypted output. It does not. A passphrase is required to open encrypted input, and it is required again if you choose PKCS#8 encrypted for the output. Parsing and re-encrypting are separate decisions.
Before copying the result, pause on Detected Input, Key Kind, Key Size (bits), Modulus SHA-256 (hex), and SPKI pin (sha256/base64). If those fields look right, move to Converted Output. If they do not, fix the source or the selected wrapper before exporting anything.
Step-by-Step Guide:
Use the page in two passes: identify the source first, then create the target wrapper.
- Paste the full PEM block or upload a key file. A successful parse fills the summary area and the
Key Detailstab, includingDetected InputandKey Kind. - If an encrypted private key was pasted and the page shows a passphrase error, open
Advanced, enter the passphrase, and try again with the completeBEGINandENDblock intact. If the parser still fails, the source is not a supported PEM-encoded RSA key. - Leave
Output formatonInfo onlyuntilKey Size (bits),Public Exponent (e), and the digest fields look plausible for the key you meant to load. - Choose the target wrapper. Use one of the public outputs when
Key KindisPublic. UsePKCS#1 private,PKCS#8 private, orPKCS#8 encryptedonly when the input is private material. AdjustPEM wraponly if the destination parser asks for a specific line width. - If you choose
PKCS#8 encrypted, enter the output passphrase inAdvancedbefore continuing. Then read the generated PEM inConverted Output. - Open
JSONonly if you need a structured audit record. If the goal is simple same-key verification, stay inKey Detailsand compare the digest fields instead of copying the whole PEM.
That order keeps the check fields in front of the export so a wrapper mistake does not slip into deployment.
Interpreting Results:
Detected Input is the first field to trust. It tells you which PEM object actually parsed, not what the file was named. Key Kind and Key Size (bits) then tell you whether private outputs are even possible and whether the modulus length matches policy or expectation.
- If
Key KindisPublic, any private-key output request is a category mistake. The secret values are not present. - If
Detected Inputchanges after adding a passphrase, the original PEM was encrypted and the page is now reading the unlocked key structure rather than the locked container alone. - If two files show the same
SPKI pin (sha256/base64), they describe the same public key even when one is private and the other is public. - If two files show the same
Modulus SHA-256 (hex)but different wrapper labels, the RSA numbers match. The remaining question is only whether the destination accepts that wrapper.
Do not overread the PEM text itself. Matching header lines do not prove a key matches, and different header lines do not prove it changed. The safe verification step is to compare the digest fields first, then confirm that Selected Output matches the format the destination asked for.
Worked Examples:
Legacy server key into a newer library
An older host hands over an RSA PRIVATE KEY file. After paste, Detected Input shows PKCS#1 and Key Kind shows Private. Selecting PKCS#8 private changes Selected Output to the generic private wrapper most modern loaders expect, while the digest fields stay tied to the same key.
Public PEM for a legacy RSA-only consumer
A device accepts only RSA PUBLIC KEY, but the available file is a generic PUBLIC KEY. When Detected Input shows SPKI public and Key Kind shows Public, selecting PKCS#1 public keeps the same public identity and changes only the wrapper shown in Converted Output.
Encrypted key that will not open
A pasted ENCRYPTED PRIVATE KEY block produces a passphrase error instead of filling Key Details. Entering the passphrase in Advanced lets the page populate Detected Input, Key Size (bits), and the digest fields. From there, you can keep Selected Output on PKCS#8 encrypted for a protected export or switch to a clear private wrapper if policy allows it.
FAQ:
Does conversion change the RSA key itself?
No. The key's public identity stays the same unless a different key was loaded. The wrapper changes, and private output can gain or lose passphrase protection, but Modulus SHA-256 (hex) and SPKI pin (sha256/base64) help confirm that the public key did not change.
Why do two PEM files look different when the key is the same?
PEM label choice, line wrapping, and private-key encryption can all change the printed text. Compare SPKI pin (sha256/base64) or Modulus SHA-256 (hex) instead of comparing the visible base64 body line by line.
Why does the page say a passphrase is required?
That error appears when the pasted input is an encrypted private key. Open Advanced, enter the passphrase, and make sure the full PEM block is present. If the source is only a public key, no passphrase can unlock private values that are not there.
Can a public key be turned back into a private key?
No. When Key Kind is Public, the source contains only the public numbers. The page can rewrap those numbers as PUBLIC KEY or RSA PUBLIC KEY, but it cannot recreate missing private material.
Are the key and passphrase sent to a server?
No server-side conversion helper is present here, so parsing and conversion stay in the browser. That still leaves the local risks you would expect with secrets: copied text, downloaded PEM files, and the live browser session remain sensitive.
Responsible Use Note:
Current processing stays in the browser and there is no server-side conversion helper. That protects against network transmission during normal use, but it does not make private material harmless. The PEM text, the passphrase you type, the clipboard copy, and any downloaded output remain exposed to anyone who can inspect this device or session.
Use the page only on a system you trust, clear the key text when you are done, and treat any exported PRIVATE KEY or ENCRYPTED PRIVATE KEY file as a live secret rather than as throwaway scratch output.
Glossary:
- PKCS#1
- The RSA-specific ASN.1 family used by
RSA PRIVATE KEYandRSA PUBLIC KEYwrappers. - PKCS#8
- A generic private-key container format used by
PRIVATE KEYandENCRYPTED PRIVATE KEY. - SubjectPublicKeyInfo
- The generic public-key structure behind the PEM label
PUBLIC KEY. - PEM
- Base64 text wrapped between
BEGINandENDboundary lines around DER-encoded data. - Public exponent
- The RSA value
e, shown as an inspection field alongside the modulus size. - SPKI pin
- A base64 SHA-256 digest of the DER-encoded SubjectPublicKeyInfo structure, used to compare public-key identity across wrappers.
References:
- RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures, IETF, April 2015.
- RFC 5958: Asymmetric Key Packages, IETF, August 2010.
- RFC 8017: PKCS #1: RSA Cryptography Specifications Version 2.2, IETF, November 2016.
- RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, IETF, May 2008.
- RFC 7469: Public Key Pinning Extension for HTTP, IETF, April 2015.
- rsa - RSA key processing tool, OpenSSL documentation.
- pkcs8 - PKCS#8 format private key conversion tool, OpenSSL documentation.