URL decoder

What Is URL Decoding?

URL decoding — also called percent-decoding — is the reverse of URL encoding: it converts a percent-encoded string back into readable text. Where encoding turns "Hello World" into "Hello%20World" for safe travel inside a web address, decoding turns "Hello%20World" back into "Hello World" for human reading. Every %XX sequence is replaced with the byte it represents, and multi-byte UTF-8 sequences are reassembled into the original characters.

You need URL decoding whenever you work with the raw form of web addresses. Server logs record the encoded URL, not what the user typed. Analytics exports show campaign parameters as %XX soup. API debugging requires comparing what was sent against what arrived. Phishing analysts decode suspicious links to reveal the true destination hiding behind layers of encoding. In each case, the encoded string is machine-readable but human-hostile, and decoding restores the meaning.

Decoding also exposes a subtlety that encoding hides: the same decoded text can have multiple encoded forms. A space can be %20 or + (in query strings). Case varies: %2f and %2F decode identically. UTF-8 characters can be encoded byte-by-byte in only one correct way, but broken encoders produce invalid sequences that decoders must handle gracefully. A good decoder normalizes all of this back to the single intended string — and when it can't, it tells you exactly which sequence failed instead of guessing silently.

The WebTaskTools URL decoder converts any percent-encoded text back to readable form instantly, with proper UTF-8 reassembly for non-English content. It needs no setup and handles strings of any practical length. Input is processed instantly and never stored. For the forward transformation, use our URL encoder; for Base64 data, see our Base64 decoder.

How to Use the URL Decoder

1. Paste the encoded text. Copy the percent-encoded string — from a server log, an analytics export, an API trace, or an address bar — and paste it into the input box.
2. Include the full value. Make sure you copied the complete %XX sequences; a truncated sequence like %2 at the end can't be decoded.
3. Click Decode. The tool instantly converts every %XX sequence back to its character and reassembles UTF-8 multi-byte characters.
4. Read the result. The decoded text appears in the output box — now human-readable.
5. Check for double encoding. If the output still contains %XX sequences, the input was encoded twice; decode the output again. Triple encoding is rare but follows the same rule: keep decoding until the text stabilizes.
6. Copy or clear. Copy the decoded result for your notes or analysis, then clear for the next string. The tool handles unlimited decodes per session, so long log files can be worked through value by value.

Decoding in Action: Before and After

Key Features

• Instant decoding — paste encoded text and read the result immediately.
• Full UTF-8 reassembly — multi-byte sequences for Urdu, Arabic, Chinese, emoji, and accented Latin decode correctly.
• Plus-to-space handling — correctly interprets + as space in query-string context.
• Case-insensitive hex — %2f and %2F decode identically, per the spec.
• Double-encoding detection aid — residual %XX in output signals another decode pass is needed.
• Graceful error handling — truncated or invalid sequences are flagged, not silently dropped.
• Not stored — input is processed instantly and never stored, logged, or retained.
• Free and unlimited — decode as much as you need at no cost, with no accounts and no quotas.

The Plus Sign Problem

The + character is URL decoding's most persistent gotcha, because it means different things in different parts of a URL. In the query string, following the HTML form-encoding convention (application/x-www-form-urlencoded), + represents a space — so q=fish+chips decodes to "fish chips". In the path, however, + is a literal plus sign — /files/a+b refers to a file genuinely named "a+b".

This split causes real bugs. A filename containing "+" uploaded via a form gets stored correctly, but a download link built by naively decoding the path turns "a+b" into "a b" and 404s. Conversely, a search term "C++" encoded properly as "C%2B%2B" survives everywhere — the bug only strikes when someone "helpfully" decodes + to space in the wrong context. The rule: apply form-decoding (+ → space) to query strings only; decode paths with strict percent-decoding where + stays +. When debugging, always check where in the URL the + appeared before deciding what it meant.

Use Cases

Developers debugging web requests

The problem: Server logs show GET /search?q=%D9%85%D8%AB%D8%A7%D9%84 — what did the user actually search for? The encoded form is unreadable, and guessing wastes time.

How this tool helps: Paste the encoded query value and read the original search term instantly. Comparing decoded values against expected input isolates whether the bug is in encoding (client) or handling (server).

SEO analysts

The problem: Crawl reports and log files list URLs in raw encoded form. Spotting patterns — which non-English URLs 404, which parameter combinations appear — is nearly impossible in %XX soup.

How this tool helps: Decode URL lists in batches to readable form before analysis, making patterns visible. It's also the fastest way to verify that a redirected URL resolves to the intended destination.

Security analysts and phishing investigators

The problem: A suspicious link arrives as https://trusted-bank.com%2Eattacker.com/login%3Fsession%3Dabc — or with multiple encoding layers deliberately obscuring the true destination.

How this tool helps: Decode layer by layer until the true hostname and path are revealed. Encoded dots (%2E), slashes (%2F), and at-signs (%40) are classic obfuscation tricks; decoding strips the disguise. (Analyze in a safe environment — never visit the decoded link directly.)

Marketers auditing tracking

The problem: Analytics shows campaign names as encoded strings, and attribution reports need the human-readable values to make sense to stakeholders.

How this tool helps: Decode UTM parameter values from exported data to recover the original campaign, source, and content names for clean reporting.

QA engineers

The problem: Test cases assert on URL contents, but the app under test produces encoded output while the test data is in plain text — comparisons fail on %XX differences that are actually correct.

How this tool helps: Decode actual output before asserting, or encode expected values with our URL encoder, so tests compare like with like instead of failing on encoding artifacts.

Data analysts cleaning web data

The problem: Scraped datasets contain URLs and referrer fields in encoded form, and analysis (grouping by search term, counting page views) requires the decoded values.

How this tool helps: Decode URL fields during data cleaning so downstream grouping and aggregation operate on readable text rather than encoded variants of the same value.

How Servers Actually Parse a URL, Step by Step

Understanding decoding requires understanding what happens before it. When a request arrives, the server parses the URL in a strict order, and decoding happens at a specific point in that pipeline. First, the server splits off the fragment — everything from # onward never reaches the server at all; it's purely client-side. Next, it splits the query string from the path at the first ?. Then it splits the path into segments at each /. Only after this structural parsing does percent-decoding run, and critically, it runs per component: each path segment and each query name/value is decoded independently.

This ordering explains several classic behaviors. An encoded slash (%2F) inside a path segment does not split the segment — decoding happens after splitting, so %2F decodes to a literal "/" character within one segment rather than becoming a separator. (Some servers, notably Apache with default settings, reject %2F in paths outright as a security measure.) An encoded question mark (%3F) in a query value doesn't start a new query string, for the same reason. And a %23 in a value doesn't truncate anything — the fragment split already happened on the raw string before decoding.

Frameworks add their own layer: Express, Django, and others decode query parameters automatically before your handler sees them, which means by the time your code runs, %20 is already a space. Bugs arise when developers decode again — turning a legitimate %25 (literal percent) into %, then misinterpreting what follows. The rule for application code: trust the framework's single decode, validate the result, and only decode manually when you're working with raw, undecoded strings (log lines, scraped data, protocol-level debugging).

Common Decoding Bugs and Their Fixes

Encoding Layers in a Modern Web Stack

A single user-visible string can pass through five or six encoding layers between browser and database, and each layer has its own rules. The browser percent-encodes the URL. The web server decodes it. The framework may decode again for routing. The application HTML-encodes the value for display (& becomes &). The database driver escapes it for storage. A JSON API then string-escapes it once more. Each layer is correct in isolation; bugs happen at the boundaries, when one layer's output becomes another layer's input without the proper transformation.

The professional discipline is context-aware encoding: encode for the next context, at the moment of transition, and decode exactly once when crossing back. Store the raw value; encode on output. This single principle — raw in storage, encoded at each boundary — eliminates the majority of double-encoding bugs, XSS vulnerabilities from unencoded output, and the mysterious %25 sequences that plague hand-rolled URL builders. When debugging a multi-layer issue, decode step by step from the outermost layer inward (this tool handles the URL layer), verifying the value at each stage until you find the layer that transformed it incorrectly.

Worked Example: Decoding a Server Log Line

Consider this anonymized line from a web server access log:

203.0.113.45 - - [29/Sep/2026:10:15:02 +0500] "GET /search?q=%D9%84%DB%8C%D9%BE+%D9%B9%D8%A7%D9%BE&lang=ur&page=2 HTTP/1.1" 200 18432

A junior analyst sees gibberish; a practiced one reads it fluently. Breaking it down: the client IP made a GET request to /search with three query parameters. The q value is %D9%84%DB%8C%D9%BE+%D9%B9%D8%A7%D9%BE — pasting this into the decoder (with + → space handling for the query context) reveals an Urdu search phrase of two words. lang=ur and page=2 need no decoding. The 200 status and 18,432 response bytes tell you the search succeeded and returned a full results page.

This is the daily reality of log analysis: 90% of the skill is quickly converting between encoded and decoded forms. Analysts keep a decoder open all day, paste values from logs, and read the story the raw bytes tell — what users searched for, which encoded parameters correlate with errors, whether attack probes (look for %2E%2E, %3Cscript, %00) are hitting the site. The encoded log preserves byte-accuracy for forensics; the decoder restores human readability for judgment. Both matter, and fluency in moving between them is what separates effective analysts from ones who stare at %XX soup.

Frequently Asked Questions

What does %20 decode to?

A space. %20 is hex 20 (decimal 32), the ASCII code for the space character. It's the single most common percent-encoded sequence, appearing wherever spaces were encoded in URLs.

Why does + sometimes decode to a space?

In query strings, the HTML form-encoding convention treats + as a space. This applies to the query part of URLs only — in paths, + is a literal plus. If your decoded path shows unexpected spaces, the decoder applied form-decoding where strict decoding was appropriate.

The output still has % signs — is it broken?

Probably double-encoded. Decoding %2520 yields %20 (the %25 becomes a literal %), leaving a valid-looking encoded sequence. Decode the output again: if the second pass yields clean text, the input was encoded twice — a common bug when one system encodes a value another system already encoded.

How do I decode non-English URLs?

Paste them in — the decoder reassembles UTF-8 multi-byte sequences automatically. %D8%A8%DA%91%DB%8C becomes بڑی, %E4%B8%AD%E6%96%87 becomes 中文. If you see mojibake (é instead of é) instead, the original was encoded as Latin-1 rather than UTF-8, which is a source-data problem no decoder can fully fix.

Can decoding be a security risk?

Decoding itself is just a transformation, but decoded output deserves suspicion: it may reveal a phishing URL, a path-traversal attempt (../), or script content. The security rule is to validate the decoded value — checking the encoded form is meaningless since attackers choose the encoding. Never act on (visit, execute, fetch) a decoded suspicious string.

Why do %2F and %2f decode to the same thing?

Hex digits in percent-encoding are case-insensitive per RFC 3986: %2F, %2f, and even mixed case all represent byte 0x2F (/). Encoders conventionally emit uppercase, but decoders must accept both. If a system treats them differently, that system has a bug.

What's the difference between decodeURI and decodeURIComponent?

They mirror the two encoders: decodeURI() decodes a full URI but leaves encoded reserved characters (%3A, %2F, %23…) intact, while decodeURIComponent() decodes everything, including those. Use decodeURIComponent for individual values you've extracted; using it on a full URL can corrupt the structure if the URL legitimately contains encoded reserved characters.

My decoded text shows replacement characters — why?

The byte sequence wasn't valid UTF-8. Either the source encoded text in a different charset (Latin-1, Windows-1252) or the %XX sequence was truncated mid-character. Check the source encoding; if it's a legacy charset, you'll need a decoder configured for that charset rather than UTF-8.

Should I decode before or after validating input?

Decode first, then validate the decoded value. Validating the encoded form is unreliable — %2E%2E and ".." are the same attack in different clothes, and a validator that only recognizes one misses the other. Decode exactly once at the trust boundary, validate the result against an allowlist, and never decode the same input twice.

Is my pasted data stored?

No. Decoding is processed instantly and the input is never stored, logged, or retained. Encoded strings occasionally contain session tokens, so as a standing habit prefer your own environment for live production data; development and debugging pastes are fine here.