Private Key Inspector
Verify private key details, algorithm, and passphrase safety locally.
Private Key Inspector
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The Private Key Inspector reads a PEM-formatted private key file and reports its format, algorithm, key size, and whether it's passphrase-protected — without ever transmitting the key itself anywhere. Private keys come in more than one wrapper format depending on when and how they were generated, and confusing one for another is a common source of 'invalid key' errors when configuring a server or client that expects a specific format.
- The two formats you'll encounter most: PKCS#1 (headers read -----BEGIN RSA PRIVATE KEY-----), the older, RSA-specific format; and PKCS#8 (headers read -----BEGIN PRIVATE KEY----- or -----BEGIN ENCRYPTED PRIVATE KEY-----), a newer, algorithm-agnostic wrapper that works for RSA, elliptic curve, and other key types uniformly. Most modern tooling generates and expects PKCS#8, but PKCS#1 keys remain common in older configurations and some tools' default output.
How It Works
- The PEM header is read first to identify the wrapper format — PKCS#1 (RSA-specific) or PKCS#8 (algorithm-agnostic), and whether the PKCS#8 variant indicates encryption.
- The key's algorithm (RSA, EC, and similar) and size (in bits, or curve name for elliptic curve keys) are read from the underlying key structure.
- The presence of passphrase protection is checked — either through a PKCS#8 EncryptedPrivateKeyInfo wrapper, or the older OpenSSL-specific 'Proc-Type: 4,ENCRYPTED' header sometimes seen on legacy PKCS#1 keys.
- The results are displayed without ever requiring the key to leave your browser — all parsing happens locally.
Usage
- Paste the PEM-formatted private key you want to inspect.
- Run the inspection.
- Review the reported key format (PKCS#1 or PKCS#8), algorithm, size, and passphrase-protection status.
- Use this information to convert the key format if needed, or to confirm it matches what your target system expects.
Examples
- Inspecting a key that fails to load in a newer library to confirm it's an older PKCS#1 format the library doesn't directly support.
- Checking the key size of a private key inherited from an older system before deciding whether it needs to be regenerated to meet a current minimum-strength policy.
- Confirming a key is passphrase-protected before including it in an automated deployment pipeline that would need to supply that passphrase non-interactively.
- Verifying that a private key generated by one tool (e.g. the SSH Key Generator) is in the expected format before using it with a different, unrelated tool.
Real-World Use Cases
- Diagnosing an 'unsupported key format' or 'invalid key' error by confirming whether a key is actually PKCS#1 or PKCS#8, since some libraries and server software only accept one.
- Confirming a private key's algorithm and size before deploying it, to check it meets a security policy's minimum key-strength requirements.
- Checking whether a key is passphrase-protected before scripting an automated deployment that would otherwise unexpectedly prompt for a password (or fail silently) if the key turns out to be encrypted.
- Verifying a private key you generated with one tool is actually in the format a different downstream tool or server expects, before troubleshooting further.
Best Practices
- Prefer PKCS#8 for new keys where you control generation — it's algorithm-agnostic and more broadly supported by current tooling than the RSA-specific PKCS#1 format.
- Use passphrase protection on private keys stored at rest wherever your deployment process can accommodate supplying it, especially for keys with any real-world exposure risk.
- Confirm a key's algorithm and size meet your organization's current minimum requirements before deploying it, rather than assuming an inherited key is still adequate.
- Never paste a real production private key into any browser-based tool, including this one, for anything beyond one-off inspection in a controlled, trusted environment — treat any key entered anywhere outside your own key management system as potentially exposed.
Common Mistakes
- Assuming all private keys are interchangeable regardless of PEM header — a tool expecting PKCS#8 will reject a PKCS#1 key outright, and vice versa, even though both represent valid RSA keys.
- Deploying an unencrypted private key to a shared or less-trusted environment without passphrase protection, when the deployment process could reasonably have accommodated one.
- Not checking key size before reuse — an inherited key from an older system may no longer meet current minimum-strength guidance (e.g. RSA below 2048 bits).
- Treating a passphrase-protected key as equivalent in risk to storing the passphrase alongside it in the same location — the protection only helps if the passphrase is actually kept separate.
Limitations
- This tool reports a private key's format, algorithm, size, and encryption status; it does not decrypt a passphrase-protected key or verify the passphrase itself.
- It does not convert between key formats — pair it with the JWK ↔ PEM Converter or your own tooling if you need to change the wrapper format itself.
- Any key pasted here should be treated as no longer fully confidential — use only throwaway test keys, or perform inspection in a fully trusted, offline context for real production keys.
Technical Reference Guide
- The PKCS#1 format (RSA-specific private key structure) is defined by RFC 8017.
- PKCS#8, the algorithm-agnostic private key wrapper now preferred by most modern tooling, is defined by RFC 5958 (which obsoletes the earlier RFC 5208 definition).
- PKCS#8's encrypted variant, used to passphrase-protect a private key within the same general structure, is also specified within RFC 5958.
FAQ
What's the difference between PKCS#1 and PKCS#8 private keys?
PKCS#1 (-----BEGIN RSA PRIVATE KEY-----) is an older, RSA-specific format. PKCS#8 (-----BEGIN PRIVATE KEY----- or ENCRYPTED PRIVATE KEY) is a newer, algorithm-agnostic wrapper that works uniformly across RSA, EC, and other key types, and is what most modern tooling expects by default.
Why does my key fail to load in a library that should support RSA?
The library may specifically expect PKCS#8 while your key is in the older PKCS#1 format (or vice versa) — check the PEM header (RSA PRIVATE KEY versus PRIVATE KEY) to identify which format you actually have.
How can I tell if a private key is passphrase-protected without trying to use it?
Check for a PKCS#8 'ENCRYPTED PRIVATE KEY' header, or on older PKCS#1 keys, a 'Proc-Type: 4,ENCRYPTED' line inside the PEM block — both indicate the key requires a passphrase before it can be used.
Is it safe to inspect a real private key with this tool?
Treat any key entered into a browser tool as no longer fully confidential, even one that only reads and doesn't transmit it. For real production keys, prefer inspecting with local, offline tooling you control end-to-end.
Does this tool convert my key to a different format?
No — it only reports the current format, algorithm, size, and encryption status. Use the JWK ↔ PEM Converter or dedicated command-line tooling for actual format conversion.
What key size should I be using in current systems?
RSA 2048-bit is a commonly accepted current minimum, with 3072 or 4096-bit for longer-term protection; elliptic curve keys (like P-256) achieve comparable security at much smaller key sizes. Check your organization's specific policy for the exact requirement.
Part of this Developer Hub
This utility is part of our comprehensive Certificate & PKI topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the Certificate & PKI Lab workshop for complementary engineering workflows.
View all Certificate & PKI Lab tools