https://wal.sh/tools/transform/

Default (no params): input = Hello, World!, chain = identity encode.

Each step in the + delimited chain follows:

<codec-id>[:<arg1>[:<arg2>...]][:<direction>]

Direction tokens: d, decode, e, encode. Default: encode. Everything between the codec ID and the direction token is positional args.

The chain parameter has a formal grammar. The three character classes (codec ID, arg, direction token) are disjoint by construction, which makes parsing unambiguous with no lookahead.

;; In the URL (before decode):
chain   = step ("+" step)*

;; After URL decode (+ becomes space):
chain   = step (" " step)*

;; Per-step grammar (same either way):
step    = id (":" arg)* (":d")?
id      = [a-z][a-z0-9-]*       ; lowercase alpha start, then alphanumeric or hyphen
arg     = <any segment that is not "d">
dir     = "d"                    ; decode. absence = encode (the default).

One reserved word: d. A trailing :d always means decode. It can never be an argument. Encode is the default and has no suffix.

That is the entire parsing rule. The last colon-segment is checked:

• If it is exactly "d" → direction is decode, remove it from args
• Otherwise → direction is encode, it stays as an arg

:e, :encode, and :decode are accepted on input for tolerance but never emitted. steps->str produces :d or nothing.

In URL query strings, + encodes a space. Standard URL decoding (URLSearchParams, decodeURIComponent, url.parse, Ring, etc.) converts + to space before the application sees the value. This means:

URL:        ?chain=rot13+base64:d+caesar:3:d&text=Hello+World
URL decode: chain = "rot13 base64:d caesar:3:d"
            text  = "Hello World"

After URL decoding, the chain value is a space-separated list of step tokens. Every language's default string split works:

No custom delimiter logic needed. URLSearchParams is safe to use.

Canonical output: steps->str MUST emit + (which URL-encodes space). This keeps the URL readable: ?chain=rot13+base64:d looks like a pipeline, not ?chain=rot13%20base64%3Ad. Implementations that use URLSearchParams to construct URLs will naturally emit + for spaces in form encoding mode.

f(f(x)) = x. One function. Direction is irrelevant. Verb: apply.

Registry shape: {:id :rot13 :label "rot13" :fn rot13 :involution? true :inverse? true}

decode(encode(x)) = x but encode ≠ decode. Two separate functions. Verb: encode or decode.

Registry shape: {:id :base64 :label "base64" :encode encode-fn :decode decode-fn :inverse? true}

A factory function receives [args] dir and returns (string → string). The same arg means different things depending on direction.

Registry shape:

{:id :caesar :label "caesar"
 :make-fn (fn [args dir]
            (let [n (parse (first args))
                  shift (if (= dir :decode) (- 26 n) n)]
              #(rot-n shift %)))
 :inverse? true :involution? false}

Note: the shift N is applied mod 26, so every integer is a valid argument and no range check is needed — caesar:0 and caesar:26 are both the identity, caesar:13 is rot13, caesar:-1 equals caesar:25. The examples below cover the cases; the formal domain is left for the reimplementation to synthesize.

Case is preserved: [A-Z] shift within uppercase, [a-z] within lowercase, and every other character (digits, punctuation, spaces, non-ASCII) passes through unchanged. So rot13 applied to [VADER] No. I am your father. yields [INQRE] Ab. V nz lbhe sngure. — brackets, period, spaces, and case all intact.

caesar:13 is the only codec where direction changes the shift amount rather than selecting a different function.

Information is destroyed. Verb: apply. Decode is nil or cosmetic. Pipeline turns red/amber at this step.

Registry shape: {:id :sort :label "sort" :encode sort-fn :decode nil :inverse? false}

Identical to Clojure's (-> input f1 f2 f3).

1. Start with text param as initial value
2. For each step left-to-right, resolve the function and apply it
3. Record the intermediate value after each step (the trace)
4. Halt on first error

The trace is the core data structure — it drives both the visual overlay and the output.

Given a step {:id :base64 :direction :encode :args []}:

1. Look up codec by :id
2. If codec has :make-fn: call (make-fn args direction) → function
3. If codec has :fn: use it (involution, direction irrelevant)
4. Otherwise: (get codec direction) → :encode or :decode function

A step is reversible when:

(and (:inverse? codec)
     (or (:involution? codec)      ; f = f⁻¹
         (:make-fn codec)          ; factory handles both directions
         (some? (get codec (opposite direction)))))  ; partner fn exists

A pipeline is reversible when every step is reversible.

To invert a pipeline:

1. Reverse the step order
2. Flip each step's direction (:encode ↔ :decode)
3. Involutions keep :encode (direction is irrelevant — they use :fn)
4. Surjections keep :encode (no :decode exists — best effort)
5. Preserve :args — parameterized codecs need their arguments

;; Forward:  [{:id :caesar :direction :encode :args ["3"]}]
;; Reversed: [{:id :caesar :direction :decode :args ["3"]}]
;; The "3" stays — make-fn interprets it as shift-23 when dir=:decode

Implementation note on involutions: In implementations using separate encode~/~decode fields (OCaml, Rust, TypeScript), an involution stores the same function in both fields. Flipping the direction is harmless — it still resolves to the same function. But in implementations using a single fn field (Clojure, Racket), the function resolution logic checks :fn first and ignores direction entirely. If the reverse-pipeline code sets direction to :decode on an involution, the resolution logic MUST still find the function. The safest approach: always set involution steps to :encode in the reversed pipeline (matching the canonical serialization).

Forward:   rot13(encode) + base64(encode) + hex(encode)
Reversed:  hex(decode) + base64(decode) + rot13(encode)
                                           ^^^^^^ encode, not decode

Pipeline → URL chain param:

• Join steps with +
• Each step: <id> (encode) or <id>:d (decode)
• With args: <id>:<arg1>:<arg2> or <id>:<arg1>:d
• Encode direction is the default — the :e suffix is DROPPED. rot13 means encode. rot13:d means decode. There is no rot13:e in canonical output.

URL chain param → pipeline. The algorithm has two levels of splitting: an outer split on step delimiters and an inner split on the colon separator within each step.

str->steps(steps->str(pipeline)) = pipeline for all valid pipelines. The reverse does NOT hold: steps->str(str->steps("rot13:e")) = "rot13" (the explicit :e is normalized away). Implementations MUST accept both forms on input but produce only canonical form on output.

For every reversible chain, threading input through the chain and then through the reversed chain MUST return the original input:

(let [steps  (str->steps "caesar:3")
      result (thread "ET TU BRUTE" steps)        ; → "HW WX EUXWH"
      rev    (reverse-pipeline steps)
      back   (thread "HW WX EUXWH" rev)]         ; → "ET TU BRUTE"
  (assert (= "ET TU BRUTE" (:value (last back)))))

step-reversible? checks registry flags (:inverse? true), not runtime behavior. A codec could claim :inverse? true while its decode function is broken. Implementations MUST NOT rely on the flag alone for round-trip guarantees. The flag is a UI hint for the badge; the actual round-trip property is a semantic invariant that the spec asserts but does not prove.

Several codecs have restricted domains. The spec now requires these predicates for decode direction:

Attempting to decode invalid input MUST produce an error in the trace, not undefined behavior.

The spec assumes strings are sequences of Unicode code points. Implementations in UTF-16 languages (JS, Java) and UTF-8 languages (Rust, Go) MUST agree on output for ASCII input. Non-ASCII behavior is implementation-defined and should be documented per-codec.

caesar:N where encode = decode (involution) holds for N ≡ 0 and N ≡ 13 (mod 26). N ≡ 0 is the identity (caesar:0, caesar:26, caesar:-26 …). N ≡ 13 is rot13. The unique non-trivial fixed point among N ∈ {1,…,25} is N = 13.

xor encode and decode are NOT the same function. Although XOR is mathematically self-inverse (x XOR k XOR k = x), the codec's encode and decode operate at different levels:

• Encode: XOR each byte of the input with key 0x42, then represent each result byte as a 2-character lowercase hex string. Input: ASCII string. Output: hex string (twice the length).
• Decode: Parse the hex string into byte pairs, XOR each with 0x42, and reconstruct the ASCII string. Input: hex string. Output: ASCII string.

This means xor is a bijection (Pattern 2), not an involution (Pattern 1), even though the underlying XOR operation is self-inverse. The hex representation makes encode ≠ decode at the string level.

Reference implementation (Clojure):

(defn- xor-encode [s]
  ;; "Hi" → XOR each char with 0x42 → emit as hex pairs
  ;; H=0x48, 0x48 XOR 0x42 = 0x0a → "0a"
  ;; i=0x69, 0x69 XOR 0x42 = 0x2b → "2b"
  ;; result: "0a2b"
  ...)
(defn- xor-decode [s]
  ;; "0a2b" → parse hex pairs → XOR with 0x42 → chars
  ;; 0x0a XOR 0x42 = 0x48 = H
  ;; 0x2b XOR 0x42 = 0x69 = i
  ;; result: "Hi"
  ...)

Implementations that treat XOR as an involution (same function for both directions, operating on raw bytes) will fail the test vectors because the output representation differs.

The substitution table A↔4 E↔3 I↔1 O↔0 S↔5 T↔7 B↔8 G↔6 applies to uppercase letters only. Lowercase passes through unchanged. This means case is preserved and the codec is a true bijection on the mixed-case domain:

encode("BEAST")  → "83457"
encode("beast")  → "beast"    (lowercase untouched)
encode("Beast")  → "8east"    (only the B is uppercase, so only B→8)
decode("83457")  → "BEAST"
decode("beast")  → "beast"
decode("8east")  → "Beast"

hex encode MUST produce lowercase hex digits (48656c6c6f, not 48656C6C6F). Decode MUST accept both cases ([0-9a-fA-F]). This is consistent with the test vector: chain=hex&text=Hello → 48656c6c6f.

When decode receives input outside its domain predicate (e.g., hex:d on an odd-length string), the codec MUST signal failure. The representation of failure is language-specific:

The pipeline execution layer MUST catch the failure and produce a trace entry with error set and output equal to the unchanged input. Pipeline execution halts after the first error.

rot13 shifts ASCII letters and passes everything else through unchanged. The exact ranges:

• A-M (0x41-0x4D) → shift +13 → N-Z (0x4E-0x5A)
• N-Z (0x4E-0x5A) → shift -13 → A-M (0x41-0x4D)
• a-m (0x61-0x6D) → shift +13 → n-z (0x6E-0x7A)
• n-z (0x6E-0x7A) → shift -13 → a-m (0x61-0x6D)
• Everything else: pass through unchanged

Case is preserved. Digits, punctuation, spaces, and non-ASCII are untouched.

corrupt is the only non-deterministic codec. Pipelines containing corrupt violate the purity axiom ("URL → deterministic output"). The spec's axiom applies to all pipelines EXCEPT those containing corrupt. Implementations SHOULD seed the RNG from the input for reproducibility in tests, or exclude corrupt from round-trip assertions.

The spec uses "surjection" loosely. Formally, sort is non-injective (many inputs map to one output) but whether it is surjective depends on the codomain definition. The spec means: information-destroying, no left-inverse exists. The UI label ONE-WAY is more precise than the mathematical term.