Encoding infrastructure · v1.0

Your data.
Uniquely addressable.

Transform strings, URLs, webhooks, and other values into uniquely addressable endpoints. Create once. Access through a dedicated route.

128-bit
Identifiers
30
Per user key
7 days
Reset maturity

From raw string to routable endpoint.

Every encoding passes through the same three stages. Values enter once, become uniquely addressable, and are served through a dedicated route.

01
Input
// any string, up to 8 KB "https://hooks.example.com/abc"

A source string enters the system — a webhook URL, an API key, a redirect target.

02
Identifier
"id": "9f2c1a7b4e8d0c3f"

A 128-bit identifier is minted and collision-checked against the store before acceptance.

03
Endpoint
GET /d/9f2c1a7b4e8d0c3f

A dedicated route is now live. Use /d/ to read the value, or /r/ to redirect.

Illustrative visualization · not connected to production backend

Everything an encoding needs.

A focused set of primitives — nothing more — designed for the workflows developers actually have.

String encoding & storage

Any string up to 8 KB — webhook URLs, API keys, redirect targets, signed payloads — stored behind a 128-bit identifier and retrieved through a stable route.

POST /encode · payload up to 8000 chars · per-user shelf

Unique identifiers

128 bits of cryptographic randomness, collision-checked at creation. Guaranteed to never repeat.

Domain restrictions

Pin an endpoint to specific origins. Others receive a 403 before any value is served.

Dedicated decode endpoints

GET /d/:id returns the stored value as JSON. Callable directly from browser JavaScript.

URL redirect endpoints

GET /r/:id issues a 302 redirect to the stored URL. Ideal for webhooks and deep links.

Per-user management

A browser-side user key identifies your shelf. Up to 30 encodings per key, listable via GET /mine.

Value management with reset restrictions

Values are hidden from their owner after creation. They may only be reset once an encoding is at least 7 days old — a cooling-off window that keeps anything from being changed in the panic of an incident.

PATCH /d/:id · reset guarded by maturity · domains editable any time

Under the surface. Actually.

DG Encoder runs entirely on Cloudflare's edge. Requests are handled by a single Worker, storage lives in KV, and every read is served from an isolated key.

01 · CLIENT Browser / App / Server 02 · EDGE Cloudflare Worker id minting · domain check 03 · STORAGE KV Namespaces ENCODES · USERS 04 · RESPONSE Two response shapes 200 OK GET /d/:id 302 Redirect · /r/:id

Identifier generation

16 random bytes → 32 hex characters → collision-checked against the KV store before acceptance.

User keys

Issued on first encode, persisted in your browser. Grants access to GET /mine, domain edits, and resets.

Domain checks

Origin and Referer headers are compared against the allow-list on every decode and redirect request.

One-time tokens

15-character tokens, TTL 60 seconds, single-use. Minted via /get/token, redeemed via /get/value.

Five endpoints. Zero ceremony.

Plain HTTP. JSON in, JSON out. Copy any call and use it from the browser, server, or edge.

create-encoding.http

Honest about what this is.

DG Encoder is an encoding system, not an encryption system. It solves a specific problem — routable indirection — and is explicit about its boundaries.

What it is

  • Values stored behind unpredictable 128-bit identifiers.
  • Domain restrictions enforced per request via Origin / Referer.
  • Reset and delete operations gated by 7-day maturity.
  • User keys that scope management operations to a single owner.

What it isn't

  • Not encryption. Anyone with the identifier can read the value.
  • Not cryptographic authentication. Origin headers can be spoofed.
  • Not a secrets manager. Do not store production credentials.
  • Not a substitute for OAuth, signed URLs, or access tokens.

Give your data
an endpoint.

Simple encoding. Dedicated access. Built for developer workflows.

Launch DG Encoder