Playgrounds
The library playgrounds and the MCP tool explorer run in your tab, on the published package — the CLI command builder only writes command lines: pkinative, imported from esm.sh — or from jsDelivr when esm.sh does not answer — at the exact version this site documents, which each of them names in its footer. There is no server, no upload and no telemetry: a certificate you paste never leaves the browser, which matters because the interesting ones are usually not public.
What runs is the release npm install pkinative gives you, at the same exact version — the CDN's build of npm's immutable tarball, so the same code though not the same bytes — the family's convention, shared with pdfnative and zipnative. The version is pinned and held to the manifest by the cdn-pin rule, so the playgrounds move with a release and never ahead of it: an export still under Unreleased in the changelog cannot be tried here until it ships.
Certificate inspector
Paste a certificate and read every field pkinative decodes: names, validity, public key, fingerprints, all nineteen extension kinds it decodes, and every conformance diagnostic with the clause it cites.
Open the inspector →ASN.1 tree
Walk any DER value tag by tag, with every offset and length, object identifiers resolved to their names, and a switch that lets you watch strict DER refuse what BER accepts.
Open the tree →PKI toolkit
PEM, DER and hexadecimal back and forth, object identifiers resolved, fingerprints and key identifiers, a certification request, a CRL or an OCSP response read field by field — and a chain verdict with every reason code it carries.
Open the toolkit →CLI command builder
Pick a pkinative-cli command and its subcommand, fill its flags and copy the line — with the combinations the CLI refuses with exit 2 flagged before you run it. Nothing is executed: the page builds the command, your shell runs it.
Open the builder →MCP tool explorer
Copy a client configuration, then take any pkinative-mcp tool: its tools/call payload, and the engine call behind it run in this tab on a sample or a file you drop, with what only the server can do said plainly.
Try to break them
The library pages treat a refusal as a result, not as an accident. Truncate a sample, flip an octet, feed them a private key or a JPEG: what comes back is a PkiError with its stable code, its subclass, and the byte offset where the decoder stopped. That is the error registry — 57 error codes, each with a remedy, a standard and a CWE — firing on bytes you chose rather than on an example somebody wrote down. The errors guide is the whole list.
What they leave to the library
The toolkit's chain verdict runs on the sample chain, anchored at the root it ships with and judged at an instant inside its validity: a real verdict, through verifyCertificateChain and Web Crypto, but not one about a certificate you depend on. Trusting yours needs an anchor you chose and revocation data a static page cannot fetch for you, so the inspector and the tree stay with what one pasted certificate can show honestly — a fingerprint proves two byte strings are the same certificate, and nothing about whether it should be trusted. The use cases walk through verification end to end, and the choosing guide says when another tool fits better.
The command line and the MCP server
pkinative-cli and pkinative-mcp are Node.js programs: they read and write files, and the MCP server talks to a client over stdio or HTTP. Neither can run in a tab, so their playgrounds do what a page can do honestly — the builder writes the exact command line, the explorer the exact tool call and the client configuration, and both run nothing they cannot show. The CLI guide and the MCP guide are the references.