URL decode

URL decode applies the browser's decodeURIComponent operation to the entered string. It replaces valid percent-encoded byte sequences with their decoded characters. Hello%20world becomes Hello world, %2F becomes a slash, and %E2%9C%93 becomes a check mark after the UTF-8 bytes are decoded. The tool is intended for a URL component such as a query value, path segment, or copied parameter, not for fetching a web page. It shows the decoded text in a result panel and leaves the encoded source available for comparison.

Percent encoding writes a byte as a percent sign followed by two hexadecimal digits. Multi-byte UTF-8 text uses several consecutive triplets, so one visible character can require multiple encoded bytes. Decoding reverses that representation when the sequence is valid UTF-8. Characters that are not part of percent triplets usually pass through unchanged. A plus sign also remains a plus sign because decodeURIComponent does not apply the HTML form convention that interprets plus as a space. That distinction is important when inspecting query strings produced by form encoders.

Given campaign%20report%2FQ3.pdf, the result is campaign report/Q3.pdf. The encoded slash may have been data inside one component rather than a separator in the original URL. After decoding, that distinction is no longer visually obvious. If you plan to rebuild a URL, retain the original component boundaries and encode each component separately. Do not decode an entire URL and then assume every visible slash, question mark, ampersand, or equals sign belongs to its structure.

For a query example, the raw value city=Casablanca%20Centre can be approached in two ways. If the input is only Casablanca%20Centre, the result is the intended value Casablanca Centre. If the entire city= string is entered, the equals sign remains and the value portion decodes. With application/x-www-form-urlencoded data, north+station may represent north station, but this tool returns north+station. Replace plus with space only when the producing format explicitly uses that convention and a literal plus is not intended.

decodeURIComponent throws when it encounters an incomplete percent triplet, non-hexadecimal digits after a percent sign, or bytes that cannot form valid UTF-8. Inputs such as %, %2, %ZZ, or a broken multi-byte character therefore produce an error instead of a partial result. This all-or-nothing behavior prevents the page from silently mixing decoded and invalid data. Inspect the source around each percent sign and recover missing characters from the original URL or log rather than guessing what the byte was meant to be.

An error can also indicate that text was copied through a system that truncated or rewrote percent signs. Email clients, spreadsheets, log pipelines, and templating systems may alter long URLs. Compare the input with the browser address bar or raw request record. If only one parameter is relevant, isolate its value without losing characters and decode that smaller piece. Do not repeatedly edit random percent sequences until the error disappears, because a syntactically valid replacement can still change the underlying identifier or redirect target.

The tool performs one decoding pass. A value such as %252F becomes %2F, not a slash, because %25 represents a literal percent sign. A second run would turn the remaining %2F into /. Layered encoding can be intentional when one encoded URL is carried inside another parameter. It can also be accidental double encoding. Decode one layer at a time and inspect the result after each pass. Keep the original so the number of layers and component boundaries can be reconstructed.

Repeated decoding can be dangerous in routing or security analysis. A filter may inspect one representation while a later component decodes again, changing data into a path separator or reserved delimiter. This page does not analyze such chains or label a result safe. When debugging an application, record the value at each boundary: browser construction, proxy logging, framework parsing, application access, and downstream requests. Match each decoding step to the component responsible for it instead of applying conversions until the text looks familiar.

Decoding runs locally in the browser and does not request the decoded address. Entering a URL does not navigate to it, check whether it exists, resolve its hostname, or load resources from it. The input and result remain in page state until reset or navigation. The copy action uses the system clipboard. This separation is useful when reading a parameter without visiting an unknown destination, but the decoded text can still contain sensitive values such as email addresses, document names, session identifiers, or redirect locations.

Do not paste active credentials, password-reset tokens, signed download links, or production session values unless your rules allow them in the browser session. Local processing avoids a PWRKIT decoding request, but extensions, clipboard tools, device monitoring, and nearby observers remain separate considerations. The page has no history or secure vault. Reset removes the displayed values from the workbench state, not from any clipboard history, screenshots, source logs, or other software that already received the text.

The tool does not split a URL into scheme, host, port, path, query, and fragment. It does not perform Internationalized Domain Name conversion, normalize dot segments, reorder parameters, verify a signature, or decide whether a redirect is trustworthy. It also cannot tell whether an encoded delimiter was data or structure once the surrounding component context is missing. Use the URL parser in the target programming language when structural interpretation matters, and preserve the raw input for security and debugging records.

Decoded output is not automatically safe for HTML, JavaScript, SQL, shell commands, filesystem paths, or logs. Decoding reveals characters; it does not apply the escaping or validation required by the next destination. A decoded ampersand can split a query if inserted without encoding, and decoded markup can be interpreted if placed into an unsafe HTML sink. Keep data and syntax separate. Validate the value against the application's expected type, length, and allowed character set after decoding and before using it in another context.

If spaces remain plus signs, determine whether the source came from a form-style query encoder. This decoder follows decodeURIComponent, where plus is literal. If reserved characters appear and break a reconstructed URL, you probably decoded a whole component before placing it back into URL syntax. Work with parsed fields and re-encode each value. If percent sequences remain, the input may contain another encoding layer. Decode again only after confirming that double encoding is expected and recording the intermediate representation.

If accented text or emoji causes an error, one or more UTF-8 byte triplets may be missing, reordered, or encoded under a different character set. Recover the raw source rather than assuming a replacement. If the copied result differs from the visible panel, check clipboard transformations or destination formatting. For a known-good test, %41%42%43 should produce ABC and %F0%9F%98%80 should produce a grinning face. Those checks separate a page problem from malformed production input.

Compare the result with the raw component and identify every newly visible reserved character. Confirm expected spaces, slashes, ampersands, equals signs, question marks, hash signs, and percent signs. Check whether the value is one layer inside another URL. If it represents a callback or redirect, inspect the parsed destination and approved-host policy rather than trusting readable text. When the value enters an application, test the same decoding path the application uses. A manual result is evidence for diagnosis, not proof that production parsing is equivalent.

URL encode performs the reverse component transformation and is useful when placing reviewed text back into a URL value. HTML escape targets markup-sensitive characters and should not replace percent decoding. Base64 decode handles a different representation and should be used only when the source is actually Base64. Word counter can measure a decoded field but cannot validate it. URL decode is the narrow choice for valid percent-encoded components, with explicit handling for form plus signs, encoding layers, and the destination's own validation rules.

Record the raw URL or component before decoding, including letter case in percent triplets and the exact location where it was captured. Browser address bars, access logs, framework request objects, and analytics exports may expose different stages of processing. Label each stage instead of placing every value in one note. A raw request target can answer whether the client encoded a delimiter, while a framework parameter can show what the server delivered after its own parsing. Both are useful, but they are not interchangeable evidence.

When a defect affects one parameter, isolate the name and raw value without dropping repeated parameters. Some applications accept the first value, others the last, and others retain an array. Decoding a flattened display may hide that distinction. Keep parameter order if signatures or routing depend on it. If a proxy or framework decodes automatically, avoid adding another decode operation in application code until tests show it is necessary. An extra pass can transform encoded data into syntax at the wrong boundary.

Build a regression test from the smallest raw input that reproduced the problem. Include an ordinary ASCII value, a space, a reserved delimiter encoded as data, and a multi-byte Unicode character. Assert both the parsed component and the application's validation response. This page can help confirm each expected decoded value, but the lasting test belongs beside the production parser. That separation keeps a manual diagnostic from becoming an undocumented requirement for processing real traffic.