RSA Key Conversion
{{ keySummary || '—' }}
{{ summarySecondaryLine }}
{{ keyBits }}-bit RSA {{ keyKind }} key {{ outputLabel }} Encrypted input Pin {{ fingerprintShort }}
RSA key converter inputs
Accepted headers: PRIVATE KEY, RSA PRIVATE KEY, PUBLIC KEY, or RSA PUBLIC KEY.
Drop a PEM, KEY, PUB, or TXT RSA key onto the textarea.
Choose PKCS#8 for modern private-key imports, SPKI for public-key PEM, or Info only for review.
Enter 16-128 characters; leave 64 unless the target importer requires another width.
chars
Leave blank unless the input is encrypted or the selected output is encrypted PKCS#8.
{{ passphraseRevealStatus }}
Off accepts common whitespace; on rejects non-base64 payload characters.
{{ strictB64 ? 'On' : 'Off' }}
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] }}

                
Customize
Advanced
:

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.

Diagram showing one RSA key expressed as PKCS#1 private, PKCS#8 private, encrypted PKCS#8, SPKI public, and PKCS#1 public PEM wrappers.
One RSA key can be rewrapped for different destinations. The identity check belongs on the decoded public data, not on the printed PEM text.

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.

Common RSA PEM wrappers and what each one carries
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.

Digest styles used to compare RSA key outputs
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

  1. Read the PEM boundary lines and decode the underlying ASN.1 object.
  2. If private material is present, recover the embedded public values so both private and public wrappers can be generated from the same source.
  3. Serialize the target structure: PKCS#1 for RSA-specific wrappers, PKCS#8 for generic private-key wrappers, or SubjectPublicKeyInfo for generic public-key wrappers.
  4. 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.
  5. 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 private when software expects PRIVATE KEY or a generic asymmetric-key loader.
  • Use PKCS#1 private only when a legacy RSA-specific consumer still wants RSA PRIVATE KEY.
  • Use PKCS#8 encrypted when the same private key must be stored or handed off with passphrase protection.
  • Use SPKI public when a system wants a generic PUBLIC KEY file.
  • Use PKCS#1 public only when the destination explicitly asks for RSA 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.

  1. Paste the full PEM block or upload a key file. A successful parse fills the summary area and the Key Details tab, including Detected Input and Key Kind.
  2. If an encrypted private key was pasted and the page shows a passphrase error, open Advanced, enter the passphrase, and try again with the complete BEGIN and END block intact. If the parser still fails, the source is not a supported PEM-encoded RSA key.
  3. Leave Output format on Info only until Key Size (bits), Public Exponent (e), and the digest fields look plausible for the key you meant to load.
  4. Choose the target wrapper. Use one of the public outputs when Key Kind is Public. Use PKCS#1 private, PKCS#8 private, or PKCS#8 encrypted only when the input is private material. Adjust PEM wrap only if the destination parser asks for a specific line width.
  5. If you choose PKCS#8 encrypted, enter the output passphrase in Advanced before continuing. Then read the generated PEM in Converted Output.
  6. Open JSON only if you need a structured audit record. If the goal is simple same-key verification, stay in Key Details and 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 Kind is Public, any private-key output request is a category mistake. The secret values are not present.
  • If Detected Input changes 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 KEY and RSA PUBLIC KEY wrappers.
PKCS#8
A generic private-key container format used by PRIVATE KEY and ENCRYPTED PRIVATE KEY.
SubjectPublicKeyInfo
The generic public-key structure behind the PEM label PUBLIC KEY.
PEM
Base64 text wrapped between BEGIN and END boundary 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.