DEV Community: Guo

URL Encoding Explained: %20, +, Query Strings, and Common API Bugs

Guo — Wed, 30 Sep 2026 16:36:26 +0000

A URL is not one string with one encoding rule.

It has a scheme, host, path, query string, fragment, and sometimes user-controlled values inside those parts. Bugs appear when code treats all of them as interchangeable text.

The familiar examples are spaces encoded as %20 or +, a literal plus sign that turns into a space, and an API request whose query parameters break when a user enters & or #.

The fix starts with a simple question: what exactly are you encoding?

Percent-encoding protects structure

Some characters have structural meaning in a URL:

? starts a query string
& separates query parameters
= separates a parameter name from its value
# starts a fragment
/ separates path segments
% begins a percent-encoded byte

If one of those characters belongs to user-provided data, it must be encoded before it is placed into the relevant URL component.

For example, this search term is data:

coffee & tea

If it is inserted directly into a query string, the & can be read as the start of another parameter:

https://example.com/search?q=coffee & tea

The intended value should instead be encoded:

https://example.com/search?q=coffee%20%26%20tea

Percent-encoding represents bytes with % followed by hexadecimal digits. A space can become %20, & becomes %26, and a literal plus sign becomes %2B.

MDN has a useful overview of percent-encoding in URLs, including why the same character may be encoded differently in different contexts.

Why `%20` and `+` both mean space sometimes

This is where many API bugs begin.

For an ordinary URL component, a space is commonly represented as %20:

encodeURIComponent("summer sale")
// "summer%20sale"

HTML form encoding uses a related but different convention. In application/x-www-form-urlencoded data, a space is serialized as +:

const params = new URLSearchParams({
  campaign: "summer sale",
});

params.toString();
// "campaign=summer+sale"

Both strings can represent the same value in the right context.

The important distinction is that a literal plus sign is not a space. If the original value is C++ guide, a form-style query must encode the plus signs as %2B:

const params = new URLSearchParams({
  q: "C++ guide",
});

params.toString();
// "q=C%2B%2B+guide"

When that query string is parsed, + becomes a space and %2B becomes a literal plus sign.

URLSearchParams follows the application/x-www-form-urlencoded rules. MDN documents that its string parser decodes + as a space, and its serializer writes spaces as +. Read the URLSearchParams reference.

`encodeURI` and `encodeURIComponent` solve different problems

JavaScript provides two similarly named functions. They should not be swapped casually.

encodeURI() assumes that the input is already a complete URI. It preserves URL punctuation such as :, /, ?, &, =, and #.

encodeURIComponent() is for one component or value. It encodes a wider set of characters, including &, =, and #.

This is unsafe when value comes from a user:

const value = "coffee & tea";
const url = `https://example.com/search?q=${encodeURI(value)}`;

console.log(url);
// https://example.com/search?q=coffee%20&%20tea

The & remains structural. The server may interpret part of the value as another query parameter.

For an individual value, use encodeURIComponent():

const value = "coffee & tea";
const url = `https://example.com/search?q=${encodeURIComponent(value)}`;

console.log(url);
// https://example.com/search?q=coffee%20%26%20tea

For a full URL with query parameters, the URL and URLSearchParams APIs are usually clearer:

const url = new URL("https://example.com/search");
url.searchParams.set("q", "coffee & tea");
url.searchParams.set("source", "docs");

console.log(url.toString());
// https://example.com/search?q=coffee+%26+tea&source=docs

The serialized space appears as + because searchParams uses form-style query encoding. The value remains correct.

Encode values, not an entire URL by accident

A common mistake is passing a complete URL through encodeURIComponent():

encodeURIComponent("https://example.com/search?q=coffee");
// "https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dcoffee"

That output is useful only when the complete URL itself must become one value, such as a redirect parameter:

const redirect = "https://example.com/account?tab=billing";
const url = `https://auth.example.com/login?redirect=${encodeURIComponent(redirect)}`;

It is not a replacement for constructing a normal URL.

The reverse mistake is decoding a full URL or query string blindly. A decoded &, =, or # may regain structural meaning in the wrong layer. Decode the component you expect, then validate what it means.

Avoid double encoding

Double encoding happens when already encoded text is treated as raw text and encoded again.

encodeURIComponent("hello%20world");
// "hello%2520world"

% becomes %25, so %20 becomes %2520.

This is sometimes intentional. It is often a sign that one layer of the application does not know whether it receives raw or encoded data.

A practical rule helps:

Store and pass decoded values inside your application.
Encode only when constructing the URL or request.
Decode only when parsing a URL or request.
Document any boundary that intentionally expects encoded text.

The same rule applies to URLSearchParams. Give it raw keys and values:

const params = new URLSearchParams();
params.set("q", "coffee & tea");

Do not pre-encode the value before calling set().

URL encoding is not validation or security

Encoding preserves URL structure. It does not prove that a URL is allowed, trustworthy, or safe to request.

For example, percent-encoding does not:

allowlist redirect destinations;
prevent server-side request forgery;
validate an API token;
escape HTML for display in a page;
make a query parameter safe for SQL;
confirm that a URL uses HTTPS.

Those are separate checks with separate rules.

If your application accepts a user-supplied URL, parse it with new URL(), validate the protocol and host against the rules for that feature, and avoid using string replacement as a parser.

Test the cases that tend to break

When testing URL handling, do not stop at a simple word.

Use values such as:

summer sale
C++ guide
coffee & tea
a=b
100% ready
https://example.com/a?x=1
你好

These cases reveal different failures:

spaces test %20 versus +;
+ tests whether a literal plus survives form parsing;
& and = test query-string structure;
% tests malformed or double encoding;
complete URLs test component boundaries;
non-ASCII text tests UTF-8 encoding.

I built the ToolExo URL Encoder and Decoder for this exact distinction. It keeps URL component encoding and form query-value encoding separate, shows %20 versus +, encodes a literal plus as %2B in form mode, and decodes only one layer at a time.

The tool is for a single component or query value. It deliberately does not rewrite a complete URL, host name, or protocol. Those parts have their own structure and should be parsed as URLs, not treated as text.

A URL bug often looks small in a log. It can be one missing %26, one accidental +, or one value encoded twice. Keeping the URL structure separate from its data values makes those bugs much easier to prevent.

Regex Testers Can Freeze the Browser: Safer Testing with Timeouts

Guo — Mon, 21 Sep 2026 04:37:20 +0000

A regex can look harmless in code review and still lock up a page when someone pastes the wrong input.

Most of us learn regular expressions as a compact way to validate a field, find a log line, or clean up text. The trouble starts when a pattern gives the engine many ways to interpret the same characters. If the match finally fails near the end of a long string, a backtracking engine may retry a huge number of possibilities before it gives up.

That is how a small regex turns into a CPU problem.

OWASP calls this Regular Expression Denial of Service, or ReDoS. The risk is not limited to servers. A bad pattern can block a browser tab, slow a worker, or tie up an API process if untrusted input reaches it. OWASP's ReDoS overview includes examples of patterns that grow dramatically slower on carefully chosen non-matching input.

The pattern that looks innocent

Consider this regex:

/^(a+)+$/

It accepts one or more a characters. The nested + quantifiers create the problem.

For a normal input, it seems fine:

/^(a+)+$/.test("aaaaaa"); // true

Now try a near miss:

const pattern = /^(a+)+$/;
const input = "a".repeat(30) + "!";

pattern.test(input);

The final ! prevents a match. Before the engine can return false, it may try many ways to divide the preceding a characters across the inner and outer repetitions.

The issue is not that + is always dangerous. The issue is ambiguity. If two repeated parts can consume the same characters, the engine has multiple routes to explore when the match fails.

OWASP lists nested repetition and overlapping alternatives as common warning signs:

(a+)+
(a*)*
(a|aa)+
([a-zA-Z]+)*$

A warning is not a proof that a regex is exploitable. It is a signal to test the pattern with realistic and hostile inputs before it reaches production.

The browser can be part of the failure

JavaScript regular expressions run synchronously when you call methods such as test, exec, match, or replace. If a costly match runs on the main thread, the UI cannot repaint or respond to input until that work finishes.

A test tool should isolate this work where possible. A Web Worker can run the regex outside the page's main UI thread. If the test does not finish within a bounded time, the page can terminate that worker and show a useful error instead of waiting forever.

That protects the testing page. It does not prove the regex is safe in your application.

A Node.js process, a Java service, a Python worker, and a browser tab may use different engines, time limits, input limits, and resource controls. Test the pattern where it will actually run.

Rewrite the pattern around the rule you mean

The best fix is usually to remove the ambiguity.

Suppose you want to allow words separated by spaces.

This pattern has nested repetition:

/^(\w+\s?)*$/

A clearer version describes the structure directly:

/^\w+(?:\s+\w+)*$/

This says:

Match one word.
Then match zero or more occurrences of one or more spaces followed by another word.

The second version also makes the intended rule easier to explain in a code review.

Other practical safeguards help:

Put a maximum length on input before matching it.
Prefer fixed, reviewed patterns over patterns assembled from user input.
Test inputs that almost match but fail near the end.
Avoid nested unbounded quantifiers when the repeated parts overlap.
Apply server-side limits too. Client-side validation does not protect an API.

The JavaScript RegExp API is flexible, especially when patterns are built dynamically with the RegExp() constructor. That flexibility deserves care when either the pattern or the text comes from an untrusted source. MDN's RegExp reference documents the API and its constructor behavior.

Test the happy path and the near miss

A regex test case should include more than an example that matches.

For a username pattern, test:

good_name
good-name
too short
a very long value
a value that fails at the final character

For a log parser, test long lines with one bad suffix. For a URL validator, test long repeated fragments and malformed delimiters. The inputs that fail late are often more informative than the inputs that pass immediately.

A timeout is a guardrail, not a certificate

I built the ToolExo Regex Tester to run JavaScript regex evaluations in a disposable Web Worker. The tool terminates work that exceeds 500 milliseconds and flags a few risky shapes, such as nested repetition and repeated alternatives with overlapping branches.

The timeout keeps one experiment from trapping the tester. It does not certify a pattern as safe, and it does not transfer its protection to another runtime.

Use the tool to inspect matches, capture groups, replacements, and difficult test cases. Then test the same pattern with your production input limits and runtime configuration.

Keep the rule simple enough to defend

A regular expression is easier to maintain when you can explain what each repeated section consumes and why it cannot compete with another section for the same input.

If that explanation becomes hard, split the job:

Use a simple regex to check broad syntax.
Parse or validate the meaningful parts in ordinary code.
Enforce length and business rules separately.

This approach often produces clearer error messages as well. A user learns whether a value is too long, has an invalid character, or fails a business rule. They do not get a generic "invalid input" message from a pattern nobody wants to edit.

Regex remains useful. It just needs the same care we give database queries, file parsers, and every other piece of code that processes untrusted input.

How to format and validate JSON without uploading it anywhere

Guo — Sat, 12 Sep 2026 12:06:27 +0000

A JSON blob is often easiest to read after it has been formatted. That sounds harmless until the blob is an API response with customer data, a production configuration file, or a test fixture copied from somewhere you should not casually share.

The usual workflow is simple: paste it into a formatter, make it readable, copy it back.

The problem is that the formatter may be another service in the data path.

For ordinary sample data, that may not matter. For production payloads, credentials, tokens, private URLs, or customer records, it should make you stop before pasting. A local formatter is useful because parsing and formatting can happen in the browser instead of requiring a request to a server. It is still not a license to paste secrets everywhere. Clipboard history, browser extensions, screenshots, and the system you later paste into remain part of the risk.

This article covers a practical local JSON workflow, what browser validation actually proves, and where its limits begin.

Start with strict JSON, not JavaScript-like JSON

JSON and JavaScript object literals look similar. They are not the same format.

This is valid JavaScript:

const settings = {
  theme: 'dark',
  retryCount: 3,
};

It is not valid JSON. JSON requires double-quoted property names and string values. It also does not allow trailing commas.

{
  "theme": "dark",
  "retryCount": 3
}

That distinction matters when you are preparing data for an API, a package.json file, or another strict JSON consumer. The JSON specification defines a limited data model: objects, arrays, strings, numbers, booleans, and null. It does not include comments, functions, undefined, NaN, Infinity, or JavaScript shorthand syntax. RFC 8259 is the useful reference when a format dispute turns into a production bug.

Do not use eval() to "fix" JSON-like text. It turns data handling into code execution. If the input is JSON5, YAML, or a JavaScript configuration module, identify that format and use a parser intended for it.

What formatting does, and what it does not do

A formatter normally does two things:

Parse the text into a value.
Serialize that value again with chosen indentation.

In browser JavaScript, that often means JSON.parse() followed by JSON.stringify(). MDN documents both APIs and their edge cases, including serialization behavior for values that JSON cannot represent directly. JSON.parse() and JSON.stringify() are worth reading if you regularly move data between JavaScript and APIs.

Formatting makes structure visible:

{"service":"billing","enabled":true,"limits":{"daily":250,"monthly":5000}}

becomes:

{
  "service": "billing",
  "enabled": true,
  "limits": {
    "daily": 250,
    "monthly": 5000
  }
}

That makes missing brackets, unexpected nesting, and confusing field names easier to spot.

It does not prove that the data is correct for your application.

A valid JSON document can still have a wrong field name, an expired identifier, a string where an API expects a number, or an unsafe permission setting. Syntax validation is the first check, not the last one.

A safer local workflow

For non-sensitive JSON, I use this sequence:

Remove secrets before copying anything. That includes API keys, bearer tokens, passwords, signed URLs, session values, and customer data.
Validate the original text before changing it.
Format it only after it passes strict parsing.
Compare important values against the source, especially IDs, URLs, amounts, flags, and ordered arrays.
Test the final JSON with the actual destination system.

The first step is not optional just because a tool claims local processing. OWASP advises against placing sensitive data in browser storage, and browser-side handling has risks that go beyond network transmission. OWASP Web Storage guidance

For a browser-based workspace, I built ToolExo JSON Formatter and Validator. It uses the browser's strict JSON parser to validate, format, minify, or optionally sort object keys. It reports invalid syntax instead of silently adding quotes, removing comments, or guessing what malformed input was meant to say.

That last part is deliberate. Silent repair can hide the bug that generated the bad JSON in the first place.

Common errors worth recognizing

Trailing commas

This is one of the most common cases where JavaScript habits leak into JSON:

{
  "environment": "staging",
  "debug": false,
}

The comma after false is invalid because no next property follows it.

{
  "environment": "staging",
  "debug": false
}

Single quotes

JSON strings use double quotes only.

{ 'status': 'ready' }

Correct JSON:

{ "status": "ready" }

Unquoted property names

This is valid in a JavaScript object literal but invalid in JSON:

{ timeout: 3000 }

Correct JSON:

{ "timeout": 3000 }

Comments

JSON does not support comments:

{
  // used by the nightly job
  "enabled": true
}

If the destination expects JSON, move that explanation into documentation or a field with an agreed meaning. Do not assume a comment-tolerant editor means the receiving system will accept it.

Be careful when sorting keys

Sorting object keys can make reviews and diffs easier. It should not change the meaning of a normal JSON object, but it changes the text.

That matters if another system signs the original bytes, compares snapshots as text, or expects a defined canonicalization scheme. Array order is different. Arrays are ordered, so a formatter should not reorder their elements just because it can sort object keys.

If you are about to replace a file used in production, keep the original, save the formatted version as a new file, and test the new file where it will actually run.

Large integers and duplicate keys need extra attention

JavaScript numbers use IEEE 754 floating-point representation. A JSON integer may be syntactically valid but lose precision when parsed into a JavaScript Number. For identifiers, account numbers, or exact counters, use a documented string representation if precision matters.

Duplicate object keys are another interoperability trap:

{
  "region": "us-east-1",
  "region": "eu-west-1"
}

Different parsers can handle duplicate names differently. Many JavaScript workflows keep the later value, but relying on that behavior makes the data ambiguous. Reject or fix duplicate names at the source.

Formatting is a debugging aid, not a schema

A JSON formatter answers a narrow question: "Can this text be parsed as JSON?"

It cannot answer:

Does this payload match the API schema?
Are all required fields present?
Is this user allowed to submit the request?
Does the number use the correct unit?
Is the URL safe to fetch?
Does the data make sense for the business rule?

Use schema validation, server-side authorization, field validation, and integration tests for those questions.

Formatting earns its place earlier in the workflow. It makes a compact response readable, exposes a syntax error before you chase the wrong problem, and helps you review the shape of data without sending it to a third-party formatter.

That is enough to make it a useful tool. It just should not be confused with a security boundary or a full validation system.