JWK ↔ PEM Converter
Convert JSON Web Keys to PEM format and vice versa.
JWK ↔ PEM Converter
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 JWK ↔ PEM Converter translates cryptographic keys between JSON Web Key (JWK) format and PEM-encoded format, in either direction. This bridges a real, common friction point: browser-native Web Crypto APIs and most JOSE (JSON Object Signing and Encryption) libraries speak JWK, while most server-side crypto libraries, OpenSSL, and X.509 certificate tooling speak PEM — and a key that's correct in one format is simply unusable as-is by tooling that expects the other.
- The two formats describe the same underlying mathematical key material — an RSA modulus and exponent, or an elliptic curve point — just serialized differently: JWK as a flat JSON object with base64url-encoded numeric fields, PEM as a base64-encoded ASN.1 DER structure wrapped in header/footer markers. Converting between them changes the representation, not the key itself.
How It Works
- For JWK-to-PEM conversion, the tool reads the JWK's JSON fields (n/e for RSA, or crv/x/y for elliptic curve) and reconstructs the equivalent ASN.1 structure, then PEM-encodes it with the appropriate header.
- For PEM-to-JWK conversion, the tool parses the PEM-encoded key or certificate's underlying structure and re-expresses the same key parameters as JWK's flat JSON fields, base64url-encoded per the JWK specification.
- The direction is auto-detected from the input — JSON starting with a brace is treated as JWK input; a PEM block with BEGIN/END headers is treated as PEM input.
- The output represents the identical key material in the other format — no new key is generated, and no cryptographic operation beyond re-encoding takes place.
Usage
- Paste either a JWK (JSON) or a PEM-formatted key.
- Run the conversion — the tool detects which format you provided.
- Review the output in the opposite format.
- Use the converted key with whichever system or library expects that specific format.
Examples
- Converting a public key extracted with the Public Key Extractor into JWK format for a frontend application using the Web Crypto API directly.
- Converting a JWK pulled from an identity provider's published JWKS document into PEM format to configure a server-side library that verifies JWTs using OpenSSL-style key input.
- Round-tripping a key from PEM to JWK and back to PEM, to confirm the conversion preserves the underlying key material exactly.
- Converting a JWK generated with the JWK Generator into PEM format to test compatibility with a certificate-based tool that doesn't accept JSON key input.
Real-World Use Cases
- Converting a PEM-formatted public key extracted from a certificate into JWK format for a service or library that only accepts JSON Web Keys, such as many browser-based JOSE libraries.
- Converting a JWK received from an OAuth 2.0 provider's JWKS endpoint into PEM format for use with server-side tooling (like OpenSSL) that expects the PEM convention.
- Bridging a key between two systems in your own stack where one component uses Web Crypto (JWK-native) and another uses a traditional PEM-based library.
- Verifying that a key converted from one format to the other still represents the identical key material, by converting it back and comparing to the original.
Best Practices
- Always verify a converted key still functions correctly in its target system (e.g. that a converted public key can still verify a signature made with its original counterpart) rather than assuming conversion alone guarantees correctness.
- Keep track of which format a given system expects before converting — needlessly converting back and forth adds confusion without benefit if a system already accepts the format you have.
- Treat a converted private key with the same care as the original — converting formats doesn't change the sensitivity of the underlying key material.
- When integrating two systems that speak different formats, standardize on converting at the boundary consistently, rather than scattering ad hoc conversions throughout a codebase.
Common Mistakes
- Assuming JWK and PEM are different kinds of keys rather than different encodings of the same key material — converting between them changes representation, not the cryptographic content.
- Losing track of the alg or use metadata that JWK carries but PEM has no equivalent field for — converting PEM to JWK requires deciding what algorithm and usage to declare, since PEM alone doesn't specify it.
- Attempting to convert a private key to a format a public-key-only workflow actually needed, unnecessarily handling more sensitive material than the task required.
- Not verifying the converted key still works end-to-end (e.g. can still verify a real signature) before relying on it in a production integration.
Limitations
- This tool converts key material between formats; it does not generate new keys, verify signatures, or validate that a given key is otherwise well-formed beyond basic structural parsing.
- JWK's alg and use fields have no direct PEM equivalent — converting PEM to JWK may require you to specify these fields based on your own knowledge of how the key will be used, since PEM alone doesn't encode that context.
- All conversion happens locally in your browser; nothing is transmitted, but treat any private key material pasted here as no longer fully confidential.
Technical Reference Guide
- The JSON Web Key format this tool converts to and from is defined by RFC 7517.
- The PEM-encoded SubjectPublicKeyInfo structure for public keys is defined by RFC 5280; PKCS#8 for private keys is defined by RFC 5958.
- JWK Algorithm identifiers (alg values) and their required key parameters are defined by RFC 7518, relevant when converting a PEM key into a JWK that needs an algorithm declared.
FAQ
Does converting a key between JWK and PEM change the key itself?
No — both formats describe the same underlying mathematical key material, just serialized differently. Conversion changes representation only; the cryptographic content (and any operations it can perform) stays identical.
Why would I need to convert a key between these formats?
Because different tooling expects different formats — browser-native Web Crypto and many JOSE libraries expect JWK, while OpenSSL, most server-side crypto libraries, and X.509 tooling expect PEM. Converting bridges the two ecosystems.
Does a converted JWK automatically get the correct alg and use fields?
Not necessarily — PEM has no direct equivalent for these fields, so converting from PEM to JWK may require you to specify them yourself based on how you intend to use the key, since that context isn't encoded in the PEM format.
Is it safe to convert a private key with this tool?
Treat any private key pasted into a browser tool as no longer fully confidential, regardless of the direction of conversion. For real production keys, prefer offline tooling you control end-to-end.
How do I know which format my system actually needs?
Check your library's or service's documentation — Web Crypto API calls and most modern JOSE/JWT libraries expect JWK; OpenSSL commands and traditional certificate-handling code expect PEM.
Can this tool convert a private key, or only public keys?
It can process both, since the underlying conversion logic applies to either — but treat converted private key output with the same sensitivity as the original input.
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