Is my private key sent anywhere?

No. The PEM is Base64-decoded and parsed in your browser's JavaScript; the bytes never touch a network. Even so, treat private keys as secrets and avoid pasting production keys into any tool.

Which key formats are supported?

It recognises PKCS#8 (BEGIN PRIVATE KEY), PKCS#1 RSA (BEGIN RSA PRIVATE KEY), SEC1 EC (BEGIN EC PRIVATE KEY) and Ed25519 keys wrapped in PKCS#8. Encrypted keys (BEGIN ENCRYPTED PRIVATE KEY) are detected but not decrypted.

How does it tell RSA from EC from Ed25519?

For PKCS#8 it reads the ASN.1 AlgorithmIdentifier OID inside the DER: 1.2.840.113549.1.1.1 is RSA, 1.2.840.10045.2.1 is EC, and 1.3.101.112 is Ed25519. The PKCS#1 and SEC1 labels themselves also imply the type.

Does a valid format mean the key is usable?

It confirms the structure parses correctly, which catches the most common copy-paste and encoding errors. It does not verify the key against a certificate or test a cryptographic operation.

Why does my key fail with an invalid Base64 error?

Usually the BEGIN/END lines are missing, the body has stray characters, or line breaks were mangled. Re-copy the whole block including both armour lines and ensure no extra spaces were added.

What is the PEM Private Key Format Validator?

Parses a pasted PEM-encoded private key (RSA, EC or Ed25519) locally to report its key type, label, encoding and structural validity. The key never leaves your browser. Useful for developers debugging TLS certificate and SSH key configuration issues offline. It runs free in your browser on Gera Tools, with nothing uploaded.

PEM Private Key Format Validator

Name: PEM Private Key Format Validator
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

A PEM private key is a Base64-encoded DER structure wrapped in -----BEGIN ... PRIVATE KEY----- armour. When TLS or SSH setup fails, the cause is often a malformed key — wrong label, corrupted Base64 or a truncated block. This validator decodes the PEM in your browser, identifies whether it is RSA, EC or Ed25519, and reports structural validity. The key is never transmitted.

How it works

The PEM armour is matched to find the label (e.g. PRIVATE KEY, RSA PRIVATE KEY, EC PRIVATE KEY).
The Base64 body between the lines is decoded to raw DER bytes.
For PKCS#8 keys the parser walks the ASN.1 to read the AlgorithmIdentifier OID, mapping it to a key type:
- 1.2.840.113549.1.1.1 → RSA
- 1.2.840.10045.2.1 → EC (elliptic curve)
- 1.3.101.112 → Ed25519
PKCS#1 (RSA PRIVATE KEY) and SEC1 (EC PRIVATE KEY) labels imply the type directly.

Where available, the browser’s Web Crypto importKey is used as an extra structural check for PKCS#8 RSA and EC keys.

The key formats you will encounter

PKCS#8 — the modern container format Label: -----BEGIN PRIVATE KEY----- PKCS#8 is a format-agnostic wrapper that can hold RSA, EC, or Ed25519 keys. It starts with an AlgorithmIdentifier that explicitly names the key type via an OID, which is how the validator identifies what is inside. Most modern tools generate PKCS#8. If you generate a key with OpenSSL using openssl genpkey, you get PKCS#8.

PKCS#1 — RSA-specific legacy format Label: -----BEGIN RSA PRIVATE KEY----- PKCS#1 is an older RSA-only format. The label itself tells you it is RSA — no OID parsing is needed. Older versions of OpenSSL’s openssl genrsa command produce this format. Many TLS and SSH tools accept both PKCS#1 and PKCS#8 RSA keys interchangeably.

SEC1 — EC-specific format Label: -----BEGIN EC PRIVATE KEY----- SEC1 is the elliptic-curve equivalent of PKCS#1. The label implies EC. Generated by openssl ecparam -genkey without conversion.

Encrypted private key Label: -----BEGIN ENCRYPTED PRIVATE KEY----- The DER content is encrypted with a passphrase and cannot be read without decryption. The validator will recognise this label but cannot inspect the algorithm inside. To validate the underlying key type, decrypt it first: openssl pkcs8 -in encrypted.pem -out decrypted.pem.

Common failure modes and how to fix them

“Invalid Base64” error The most common cause is missing or mangled armour lines. The full block must begin with -----BEGIN PRIVATE KEY----- (or equivalent) and end with -----END PRIVATE KEY-----, with no leading or trailing spaces on those lines. Copy the entire block including both armour lines. Watch out for word-wrap that breaks the Base64 into short lines with spaces — Base64 in PEM uses 64-character line breaks with no spaces.

“Unrecognised label” error A few tools produce non-standard labels like -----BEGIN OPENSSH PRIVATE KEY----- (the OpenSSH native format for Ed25519 and newer keys) or -----BEGIN RSA PRIVATE KEY----- for PKCS#1. If the validator does not recognise your label, convert to standard PKCS#8 with: openssl pkcs8 -topk8 -nocrypt -in input.pem -out output.pem.

“DER structure invalid” error This usually means the Base64 decoded correctly but the resulting bytes do not parse as valid ASN.1 DER. Causes include a truncated paste (the block was cut off), a copy that replaced characters (some email clients mangle equals signs), or a file that was edited in a text editor that converted line endings. Try re-exporting the key from its original source.

Key passes validation but TLS still fails Structural validity means the key parses correctly — it does not mean the key matches the certificate you are trying to use it with. A valid EC key paired with an RSA certificate will always fail the handshake. Verify that the public key embedded in your certificate matches the private key: openssl x509 -noout -pubkey -in cert.pem | openssl md5 and openssl pkey -pubout -in key.pem | openssl md5 should produce the same hash.

Security note

Private keys are credentials. Even though this validator processes everything locally in your browser and never transmits bytes, treat the practice of pasting private keys into any web tool as something to do only with test or non-production keys. For production key validation, run the equivalent check with OpenSSL directly on the server or a trusted private machine: openssl pkey -in key.pem -check.