Skip to main content

Documentation Index

Fetch the complete documentation index at: https://jdcodec.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

JD Codec is a compression layer for browser-based AI agents. Most agents that drive a browser today re-read the entire page on every step. Even small actions (“click Save”, “type into the search box”) force the agent to reconsume tens of thousands of tokens of mostly-unchanged page structure. That’s expensive, slow, and noisy for the model. JD Codec replaces those full-page reads with the smallest representation that still tells the agent everything it needs: a keyframe on the first step, then deltas as the page changes.

​
A concrete example

Picture an agent helping a customer fill out a 10-page signup form. Without JD Codec, the agent re-reads the full page on every keystroke and every click — roughly 30,000 tokens of mostly-unchanged HTML, ten times over. With JD Codec, step 1 is the full snapshot (a keyframe). Step 2 is just “the email field has the user’s email in it now”. Step 3 is just “the agent clicked Next”. And so on. The agent has all the same information; it just doesn’t have to re-read the same page scaffolding ten times. Compression on a typical page-to-page transition is over 80%. The model loses nothing of substance.

​
Three pieces

The connector runs on your machine. It’s the local Model Context Protocol (MCP) server your AI client talks to. It wraps your existing browser-automation tooling (Playwright MCP, browser-use, etc.), runs an on-device Privacy Shield over every snapshot, and forwards the cleaned snapshot to the cloud. The cloud codec is the compression engine. It receives a redacted snapshot, decides whether it can produce a meaningful delta against the session’s prior state, and returns either a compressed representation or a pass-through signal (when compression wouldn’t help — e.g. a 200k-character full-table scan). Your AI agent sees the result spliced into its browser_snapshot tool response. From the agent’s perspective, nothing changed except that the snapshot is smaller and faster to reason about.

​
Why this works

Browser pages are incredibly repetitive between steps. A typical page-to-page navigation changes maybe 5-10% of what’s on screen; a typical click event changes well under 1%. The codec captures exactly that change and emits a representation that’s a small fraction of the full snapshot. The model loses nothing of substance. It still sees every interactive element, every label, every reference it needs to act. What it doesn’t see is the unchanged scaffolding it already saw.

​
Why on-device redaction

The codec does its work in the cloud. PII never reaches the cloud. The connector runs a Privacy Shield over every snapshot before it leaves your machine. Emails, credit-card numbers, phone numbers, addresses, API keys, and a long list of other categories get replaced with placeholder tokens locally. The cloud refuses any request that doesn’t carry the audit signal proving the Shield ran. Concretely: redacted values never appear in our logs, our database, our analytics, or our error responses. Only category-level counts ({ email: 2, CC_GENERIC: 1 }) flow through for observability — counts only, never the values.

​
What’s next

  • The Privacy posture page goes deeper on what’s redacted, what’s persisted, and what the cloud never sees.
  • The Sessions, tasks, steps page explains the unit framing the API uses for state and billing.
  • The API Reference is the contract surface — every endpoint, schema, and error code.