SimpleWebUtils
ENKO

Document Workflow

Fix broken URL query parameters

Diagnose malformed query strings, missing values, repeated keys, plus signs, and double-encoded parameters before shipping a redirect or API link.

Written and tested by Published: Reviewed:

How this workflow was checked

For “Repair a nested callback parameter”, we entered the documented fixture in Developer Conversion Workbench and followed “Check empty and repeated keys” before “Rebuild the link from verified values”. We compared the browser result with the stated output, then reviewed “Treating plus signs as safe text” and “Fixing the wrong layer” as separate failure boundaries.

Encoding the nested callback alone preserved utm_source as an outer parameter and kept code and status inside redirect; encoding the complete query did not pass the comparison.

Open Developer Conversion Workbench | Query, CSS, Escape, Base, and Commit Tools

Problem

Query strings fail when reserved characters are copied into values, repeated keys are handled differently by frameworks, or a value is encoded too early or too late. The link may still open, but the server receives different data than the sender intended. Diagnose the outer query structure separately from nested values: an ampersand that belongs inside a callback URL must be encoded, while the ampersands separating the outer parameters must remain delimiters.

Sources and standards

These authoritative references define the formats or security boundaries used in this workflow. Tool-specific verification is documented separately above.

When to use this

  • A redirect, webhook, or callback receives a missing or truncated query parameter.
  • A value contains `+`, `%20`, `%252F`, or `%253A` and you need to determine whether it represents a space, a reserved character, or an extra encoding pass.
  • A repeated key such as `tag=one&tag=two` behaves differently across tools or frameworks.
  • A copied API URL has a nested JSONPath, callback URL, or search query inside one parameter.

Steps

  1. Step 1

    Parse the query string as a table

    Paste the query portion into Query String Parser so each key and value is visible. Compare the parsed rows with the sender's intended fields; an unexpected row after a nested URL usually means an inner `&` was left unencoded.

  2. Step 2

    Check empty and repeated keys

    Look for empty values, duplicated keys, and unexpected parameter order. Record every repeated value before editing because some apps keep the first, some keep the last, and some preserve an array.

  3. Step 3

    Decode suspicious values once

    Use URL Encoder and Decoder for values containing `%25`, `%2F`, `%3F`, or `%26`. Decode one value exactly once, compare it with the expected plain text, and stop if the next pass would turn legitimate percent sequences into URL syntax.

  4. Step 4

    Rebuild the link from verified values

    After each key has the expected value, encode only values that contain reserved URL syntax, then rebuild the query string. Test the final link in the actual receiving app and inspect its parsed request rather than judging success only by whether the page opens.

Example

Repair a nested callback parameter

Input

redirect=https://app.example.com/finish?code=abc&status=ok&utm_source=email

Output

redirect=https%3A%2F%2Fapp.example.com%2Ffinish%3Fcode%3Dabc%26status%3Dok&utm_source=email

Common mistakes

Treating plus signs as safe text

A plus sign can mean a literal plus or a space depending on form-decoding rules. Test the target parser; replacing every plus globally can corrupt email aliases, arithmetic expressions, or signatures.

Fixing the wrong layer

If a nested URL is the value of one parameter, fix and encode that nested value rather than rewriting the outer URL structure. Encoding the complete URL also hides the separators the receiver needs to find the outer keys.

Assuming repeated keys are invalid

Repeated keys can be valid, but the receiving system must support them. Confirm whether it expects an array, first value, or last value.

FAQ

What is the safest way to fix a broken query string?

Keep the original link, parse the query into keys and values, decode suspicious values once, then encode only the values that contain reserved URL characters. Retest against the same endpoint and compare the values it actually receives.

Why did my parameter disappear after an ampersand?

An unencoded `&` inside a value starts a new parameter. Encode the nested URL or text value before adding it to the outer query string, but leave the outer separators unencoded.

Should repeated query parameters be removed?

Not automatically. Repeated keys are valid in many systems, but you must confirm how the receiving app interprets them.