JPKCom DB

Coder — Manual

The complete feature reference for the Coder: all seven encode/decode tabs, what each does, input and output, edge cases, and the limits.

Back to the overview: Coder · Open the tool: www.jpkc.com/tools/coder/

This manual documents each of the Coder's seven tabs in detail: what it does, what goes in and comes out, the edge cases, and where the limits are. The interface is in English, so the tab and button names are given in their original spelling.

Interface and operation

The tool is a single card with a tab bar at the top: HTML, HTML+, URL, Base64, JSON, JWT, and Data URI. Each tab has its own input field and its own buttons.

  • The HTML and HTML+ tabs use a CodeMirror editor with line numbers, line wrapping, and syntax highlighting (htmlmixed mode) — pleasant for longer markup snippets.
  • The URL, Base64, and JSON tabs use a plain text field with an input history (recently processed inputs are kept locally and can be reselected).
  • Almost every tab has an Encode and a Decode button (the JSON tab calls them Escape and Unescape), plus a Copy button that puts the current field on the clipboard.
  • The result is written back into the same field — so Encode and Decode operate on the same text area. If you want to keep the original, copy it out first.
  • Feedback (success, empty input, invalid input) appears as short toast notifications.

Architecture: all client-side

Important for understanding and privacy: the server only delivers the HTML page and the editor library. The encoding and decoding happen entirely in your browser via JavaScript. There is no server-side processing, no API call, and no upload of your input — not even on the JWT tab or during Data URI generation. Your tokens, files, and strings stay local.

HTML — basic entities

The HTML tab converts the three structure-critical characters into HTML entities:

  • Encode: & → &amp;, < → &lt;, > → &gt; (in that order, so the & of the generated entities is not re-encoded).
  • Decode: reverses exactly those three entities.

This is the minimum needed to display a code snippet as text without the browser interpreting it as markup. Edge case/limit: decode only recognizes the entities that encode produces (&amp;, &lt;, &gt;). Any other entities — such as &copy;, &nbsp;, or numeric ones like &#8364; — are not converted back here; for that you need the HTML+ tab or another method.

HTML+ — advanced entities

The HTML+ tab does the same as HTML but additionally covers the two characters that break attribute values:

  • Encode: & → &amp;, < → &lt;, > → &gt;, " → &quot;, ' → &#39;.
  • Decode: reverses these five entities.

Rule of thumb: if your text sits between tags, HTML is enough. If it lands in an attribute (title="…", alt="…"), use HTML+ so quotes don't break the attribute. Again: decode only recognizes these five entities, no others.

URL — URL encoding

The URL tab encodes a string for safe use in URLs and decodes it again.

  • Encode: builds on encodeURIComponent and additionally encodes the characters ~ ! ( ) ' as percent sequences (%7E %21 %28 %29 %27). Spaces become + — that is, application/x-www-form-urlencoded style (form/query encoding), not %20.
  • Decode: first turns + back into a space, then calls decodeURIComponent.

Edge case/limit: the +-for-space behavior is deliberately form-oriented. If you need a string for a path segment where a + is meant literally, keep this difference in mind. Invalid percent sequences on decode (e.g. a lone %) produce an error message rather than broken output.

Base64 — text

The Base64 tab encodes text to Base64 and decodes Base64 back to text.

  • Encode: converts the text UTF-8 safely (via TextEncoder + btoa), so accents and emoji pass through correctly.
  • Decode: reverses this (via atob + TextDecoder). If the input is not valid Base64, the tool reports an error instead of producing a garbled string.

Edge case/limit: this tab expects standard Base64 (alphabet A–Z a–z 0–9 + / with = padding). The Base64URL variant (- and _ instead of + and /) used in JWTs does not belong here — that's what the JWT tab handles, decoding Base64URL correctly internally.

JSON — escape and unescape a string

The JSON tab handles JSON string literals, not whole JSON documents.

  • Escape: turns special characters into their JSON escape sequences: \ → \\, " → \", newline → \n, carriage return → \r, tab → \t.
  • Unescape: reverses exactly these sequences.

Typical use: you want to insert a multi-line text as a string value into a JSON or code file. Edge case/limit: the tab covers the common set (\\ \" \n \r \t). Unicode escapes of the form \uXXXX as well as \b and \f are not handled. To format, validate, or restructure whole JSON documents, use the JSON Editor.

JWT — decode and display

The JWT tab splits a JSON Web Token and shows its contents. You paste the token and click Decode.

Flow:

  1. The token is split into three parts at the dots. If it doesn't have exactly three parts, you get "Invalid JWT format".
  2. The header and payload are Base64URL-decoded and parsed as JSON, then shown pretty-printed (a separate card for the header, one for the payload, each with its own Copy button).
  3. The signature is shown as a raw string — unchanged, exactly as it appears in the token.
  4. If the payload contains an exp field (expiry), the tool shows a badge: expired (with "… ago") or valid (with "expires …"), as human-readable relative time. An iat field (issued at) adds an "Issued …" badge.

Crucially — what the tool does NOT do: it does not verify the signature and does not check whether the token is authentic or tampered with. It also does not generate tokens and takes no secret and no key. The Coder is a pure decoder/inspector: it shows you what is claimed, not whether it's true. The expiry badges rely solely on the exp/iat fields in the (unverified) payload. More on this in the tips.

Edge case/limit: if a part can't be Base64URL-decoded, or the decoded content isn't valid JSON, the tool reports "Failed to decode JWT".

Data URI — file to Data URI

The Data URI tab converts any file into a Base64-encoded data: URI you can embed directly in CSS (background-image) or HTML (src).

Flow:

  1. Via Select a file you pick a file.
  2. The browser reads it locally (FileReader.readAsDataURL); a progress indicator shows the read status.
  3. The output field then holds the finished Data URI of the form data:<mimetype>;base64,<…>. The field is read-only; the Copy button puts the URI on the clipboard.
  4. Below the field, file info is shown: name, MIME type, size, and last-modified date.

Edge case/limit:

  • The MIME type comes from browser detection (file.type). If the browser supplies no type, it shows n/a — the Data URI may then carry an empty or generic type.
  • The conversion runs entirely client-side; the file is not uploaded.
  • Base64 grows the data by about a third. For large files (videos, big images) Data URIs become correspondingly long and are often impractical to embed — Data URIs pay off mostly for small assets such as icons.

Limits — at a glance

  • HTML/HTML+ decode only recognizes the entities it produces, none arbitrary or numeric.
  • URL encode uses + for spaces (form style), not %20.
  • Base64 expects the standard alphabet; Base64URL is reserved for the JWT tab.
  • JSON escapes only \\ \" \n \r \t — no \uXXXX, no \b/\f; it handles string literals, not whole documents.
  • JWT decodes only — no signature verification, no token generation, no key input.
  • Data URI depends on the browser-reported MIME type; large files produce unwieldy long URIs.

For the big picture and the audiences, see the overview; for concrete workflows, the examples. You can try everything right in the tool.