SimpleWebUtils
ENKO

Document Workflow

Encode one URL query value without breaking the outer link

Encode a search term, callback, or nested redirect as one RFC 3986 query value while preserving the outer URL's parameter boundaries and literal plus signs.

Written and tested by Published: Reviewed:

How this workflow was checked

This check paired the exact “Encode a nested search URL as one value” input with URL Encoder and Decoder. We followed “Keep the raw source value”, captured the result after “Choose the receiving convention”, and compared it with the example while treating “Including the outer key in the encoded value” and “Treating raw plus as space without checking” as explicit boundary questions.

Only the nested search URL was encoded, yielding the documented %3A, %2F, %3F, %20, and %26 sequences while leaving the outer parameter structure available to its receiver.

Open URL Encoder and Decoder | Exact Percent Encoding and Plus Rules

Problem

A query string uses `?`, `&`, `=`, `#`, `%`, and sometimes `+` as syntax. The same characters can also be data inside a search term, callback, filter, or redirect target. If a nested ampersand is pasted raw, it starts a new outer parameter; if an existing `%20` is encoded again, it becomes `%2520`; and if a literal plus is decoded with form rules, it can become a space. The reliable unit of work is one identified value, not an undifferentiated full URL.

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 `next`, `returnUrl`, `redirect_uri`, `callback`, or `state` parameter contains another complete URL.
  • A search or filter value contains spaces, `&`, `=`, `#`, `%`, a literal `+`, Korean, Japanese, or emoji.
  • A browser opens the link but the receiving application reads a truncated or split parameter value.
  • A webhook, API client, OAuth flow, or QR destination needs one reproducible encoded value.
  • You need to decide between RFC 3986 component rules and application/x-www-form-urlencoded form rules.

Steps

  1. Step 1

    Keep the raw source value

    Store an untouched copy of the exact parameter value before editing. Preserve leading or trailing spaces, literal plus signs, and any existing `%HH` sequences so you can compare later.

  2. Step 2

    Separate the outer URL from the value

    Use URL Parser or Query String Parser to identify the one key whose value is broken. Do not include the outer `key=` prefix or neighboring `&other=value` pair in the component input.

  3. Step 3

    Choose the receiving convention

    Use RFC 3986 Component for a normal query value or nested URL. Choose Form value only when the receiving system explicitly applies application/x-www-form-urlencoded rules, where raw `+` means space.

  4. Step 4

    Encode the exact value once

    Run one encode pass. Review the existing-percent warning instead of automatically encoding again; `%25` growth is evidence that another layer is being added.

  5. Step 5

    Rebuild and parse the outer link

    Place the encoded output after the original key, rebuild the full link, then parse it again. Confirm the outer query has the expected number of keys and the nested ampersands no longer split it.

  6. Step 6

    Test the actual receiver

    Open the link only in an authorized test environment and compare the value received by the application with the untouched source. Percent encoding does not validate the destination or protect secrets in the URL.

Example

Encode a nested search URL as one value

Input

https://app.example.com/search?q=jwt decoder&sort=recent

Output

https%3A%2F%2Fapp.example.com%2Fsearch%3Fq%3Djwt%20decoder%26sort%3Drecent

Common mistakes

Including the outer key in the encoded value

Encoding `next=` together with its value can leave the receiving application without the key it expects. Encode the value, then attach it to the outer key.

Using Full URL for a nested URL

Full URL mode keeps `?` and `&` active. That is useful for a top-level readable URL but wrong when the complete URL must be data inside one outer parameter.

Treating raw plus as space without checking

Component rules preserve raw `+`; form rules interpret it as space. Confirm the receiver before choosing the profile or replacing plus signs.

Encoding an existing escape automatically

An existing `%2F` becomes `%252F` in another encode pass. Add that layer only when the surrounding protocol requires it.

Putting credentials or tokens in the URL

Encoding does not conceal data from history, logs, analytics, referrers, screenshots, or link recipients. Use non-URL secret transport where possible.

FAQ

Should I encode the key, the value, or the whole URL?

For this workflow, identify and encode one value. Keep the outer key and query separators active. Encode a whole URL as a component only when that URL itself is the value.

Should a space become `%20` or `+`?

RFC 3986 Component produces `%20`. Form value produces `+`. Use the convention the receiver documents rather than replacing one form globally.

How do I preserve a literal plus sign?

Component encoding converts a literal `+` to `%2B`. Form value also serializes a literal plus as `%2B`, while raw `+` in form decode input means space.

Why did `%20` become `%2520`?

The percent sign was encoded in another pass. Determine which layer owns the value before deciding whether that second layer is required.

Can I verify the result without sending a request?

Parse the rebuilt URL and decode the identified value once to compare it with the raw source. Final behavior still needs an authorized receiver test because frameworks apply different query conventions.

Does encoding make a redirect safe?

No. It preserves transport boundaries only. The application must separately validate allowed schemes, hosts, paths, signatures, and authorization.