URL Encoder & Decoder
Perform advanced URL encoding and decoding with deep analysis. Includes standard RFC 3986 percent-encoding, strict component escaping, space-to-plus (+) form conversion, and entire-URI path preservation. Features a live URL query parameter parsing grid, double-encoding warning guards, and an interactive comparative reference flowchart.
Perform advanced URL encoding and decoding with deep analysis. Includes standard RFC 3986 percent-encoding, strict component escaping, space-to-plus (+) form conversion, and entire-URI path preservation. Features a live URL query parameter parsing grid, double-encoding warning guards, and an interactive comparative reference flowchart.
This tool is designed to provide a seamless experience for developers by handling complex operations directly in your browser with maximum speed and security.
URLs can only contain a limited set of characters defined by RFC 3986. Letters A–Z and a–z, digits 0–9, and a handful of unreserved characters (hyphen, underscore, period, tilde) can appear in a URL exactly as they are. Everything else — spaces, ampersands, question marks, equals signs, slashes in unexpected positions, Unicode characters, hash symbols — must be encoded as a percent-sign followed by two hexadecimal digits representing the character's byte value in UTF-8. A space becomes %20. An ampersand becomes %26. The copyright symbol © (UTF-8 byte sequence C2 A9) becomes %C2%A9. This mechanism is called percent-encoding.
The reason the restriction exists is structural. URLs use specific characters for specific purposes: ? separates the path from the query string, & separates query parameters from each other, = separates parameter names from their values, # marks the start of a fragment identifier. If a query parameter value itself contains an & — say a URL for searching the text "cats & dogs" — the ampersand in the search term would be misread as a parameter separator, breaking the URL structure. Percent-encoding solves this by escaping the & to %26 so the server sees cats+%26+dogs as a single parameter value rather than two separate parameters.
Two distinct JavaScript functions handle this: encodeURIComponent() encodes a string component — a query parameter name or value — by escaping everything that is not a letter, digit, or one of - _ . ! ~ * ' ( ). It is the right function for encoding a single query parameter value before appending it to a URL. encodeURI() encodes a complete URL while preserving the structural characters (: / ? # & = + @) that are already doing their job as URL delimiters. Using the wrong function is the source of many URL encoding bugs — encodeURI() on a query parameter value does not escape & and = leaving the URL structure broken.
Read the Full GuidePaste any string into the input and click Encode URL — every character that is not safe in a URL gets replaced with its percent-encoded equivalent. The result is a string you can safely include as a query parameter value, a path segment, a form field value, or anywhere else in a URL where the original string would have broken the structure. The encoding follows the encodeURIComponent specification which is the most conservative and widely compatible approach: spaces become %20, ampersands become %26, plus signs become %2B, forward slashes become %2F, and Unicode characters are encoded as their UTF-8 byte sequences. Click Decode URL and the direction reverses — every %XX sequence in the input is converted back to the character it represents. This is the direction you need when reading a URL from a browser's address bar, a log file, a redirected URL in a network trace, or an API error message that contains percent-encoded data you need to read. A URL like https://example.com/search?q=cats%20%26%20dogs&lang=en decodes to show the actual query string: q=cats & dogs, lang=en. Seeing the decoded form immediately reveals whether a query parameter was encoded correctly, whether the encoding is complete, and what the server actually received. The input field accepts both the full URL and just the fragment you want to encode or decode. If you paste a complete URL into the decoder, the tool decodes the entire string — so structural percent-encoding like the %3F that some systems use for a literal question mark within a path segment is decoded too. The result panel has a copy button so you can grab the encoded or decoded string in one click.
1. Paste your input into the Input URL or Text field — this can be a complete URL you want to decode, a raw string value you want to encode before appending it to a URL, or any partial URL fragment. The field accepts any length of text. If you want to see the tool in action first, click Load Example to populate it with a sample URL containing spaces and special characters.
2. To encode: click the Encode URL button. Every character that is not URL-safe is replaced with its percent-encoded form. The result appears in the Conversion Result panel with a copy button. This is the value you use as a query parameter value, a path segment, or anywhere in a URL where raw special characters would break the structure.
3. To decode: click the Decode URL button. Every %XX sequence in the input is converted back to the character it represents. Use this when you have a percent-encoded URL from a browser, a log file, a redirect chain, or an API error and need to read the actual decoded content. Unicode characters that were encoded as multi-byte UTF-8 sequences (%C3%A9 for é, %E2%82%AC for €) are correctly reconstructed.
4. Copy the result using the Copy button in the Conversion Result panel — the encoded or decoded string is on your clipboard ready to paste into your code, API client, documentation, or wherever you need it.
5. If you need to encode multiple query parameter values separately — for a URL you are constructing with several parameters — encode each value independently, then join them: encodeURIComponent(key) + '=' + encodeURIComponent(value). Do not encode the entire URL at once when constructing it from parts; encode the components and assemble the URL structure around them.
Half the time I reach for a URL encoder, it is because something broke and I am trying to understand why. An API call that works in Postman fails when the same URL is constructed in JavaScript. A redirect that should send users to a specific page ends up at a blank screen. A search query that works for simple terms produces a server error when the user types anything with a special character. In every case, the first diagnostic step is encoding the problematic input manually and comparing it to what the application generated — if they differ, the application's encoding logic is wrong. The decode direction is where I spend more time. URLs that travel through multiple systems — redirects, OAuth callbacks, logging pipelines, CDN access logs, API gateway logs — accumulate encoding layers. A URL I copy from a browser log might have been encoded twice: once by the application that created the URL and once again by the proxy or CDN that forwarded it. Decoding it manually in steps shows the layers and reveals what the original value actually was. Without a decoder, reading a URL like https://example.com/oauth/callback?code=eyJhbGciO%3D%3D&state=abc%2Fxyz%3D is an exercise in mental hex arithmetic. With this tool it takes two seconds. There is also the OAuth and authentication callback scenario specifically worth calling out. When an OAuth provider redirects back to your application, the authorization code and state parameter in the callback URL are often percent-encoded. If your application reads req.query.code in Express — which automatically decodes query parameters — and compares it to a raw URL string that still has percent-encoding, the comparison fails silently. Understanding what the encoded value looks like at each point in the flow is essential for debugging these kinds of authentication issues, and this tool gives you that visibility instantly.
Bidirectional — encode raw strings to percent-encoded URLs and decode percent-encoded URLs back to readable text in a single tool with dedicated buttons for each direction
Full Unicode support — multi-byte UTF-8 characters including accented letters emoji and non-Latin scripts are correctly encoded to their UTF-8 byte sequences and correctly decoded back
Handles malformed encoding — decodes URLs that have partial or inconsistent encoding gracefully rather than throwing an error on the first malformed %XX sequence
One-click copy — the result panel has a dedicated copy button so you can grab the encoded or decoded string without manually selecting text
100% browser-based — your URLs and the data they contain never leave your machine which matters when the URLs include authentication tokens session IDs or internal endpoint paths
Accepts full URLs or string fragments — you can paste a complete URL or just the portion you need to encode or decode without preprocessing
Instant results — encoding and decoding run immediately using the browser's native URL processing functions with no server round-trip
Works for API construction and debugging equally — equally useful for building correctly encoded API requests and for reading the decoded form of URLs in logs and error messages
Encoding query parameter values that contain spaces ampersands or other special characters before appending them to API request URLs
Decoding percent-encoded URLs from browser address bars or CDN access logs to read the actual query parameter values
Decoding OAuth callback URLs to inspect the authorization code and state parameter values during authentication flow debugging
Encoding file paths and filenames that contain spaces or Unicode characters for use in REST API endpoints
Decoding redirect chains where a URL has been encoded multiple times to find the original destination
Encoding search query strings before constructing API requests to ensure special characters do not break the request structure
Decoding API error messages that contain percent-encoded URLs to read the actual endpoint that caused the error
Encoding user-provided input before including it in a URL to prevent URL injection and broken request structures
Example Input
https://example.com/search?q=developer tools & more! @#$%
Example Output
Encoded: https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Ddeveloper%20tools%20%26%20more!%20%40%23%24%25 Decoded: https://example.com/search?q=developer tools & more! @#$% Note: The encoded result encodes the entire input including the URL structural characters (:, /, ?, =). To encode only the query parameter value "developer tools & more! @#$%", paste just that value — not the full URL — into the encoder.
Incomplete Encoding — Some Characters Not Escaped: If the encoded output still contains spaces, ampersands, or other special characters, check that you are encoding only the value component — not the full URL including structural characters. The encoder treats the entire input as a single string to encode. If you paste https://example.com?q=hello world and encode it, the colon, slashes, question mark, and equals sign are all encoded too (which is probably not what you want). Paste only the portion that needs encoding — the query parameter value, the path segment, or the filename — not the full assembled URL.
Double Encoding — Encoding an Already-Encoded String: If you encode a string that was already percent-encoded, the percent signs get encoded too — %20 becomes %2520 (the % is encoded as %25, turning %20 into %2520). When your application then decodes this, it gets %20 instead of a space. The result looks almost right but is off by one decode. Always check whether the input to the encoder is already encoded before encoding again. If you see %25XX patterns in your encoded output where you expect %XX, you have double-encoded. Use the decoder first to see the raw value, then encode the decoded result.
Incorrect Decoding of Non-Percent-Encoded Input: The decoder tries to convert every %XX sequence it finds. If you paste a string that contains a literal percent sign that is not part of a percent-encoded sequence — like a progress value of 75% or a percentage in a data string — the decoder may misinterpret the % as the start of an encoding sequence and produce garbled output. Percent signs in non-URL-encoded text should be %25 to be safe. If the decoded output looks wrong and your input contains bare % signs, that is likely the cause.
Plus Sign Confusion — %2B vs Literal +: URL encoding has two conventions for spaces. In application/x-www-form-urlencoded format (HTML form submission), spaces are encoded as + signs. In standard percent-encoding (RFC 3986), spaces are encoded as %20. A + sign in a query string means a space in form encoding but a literal plus sign in standard encoding. If you are decoding a query string from an HTML form submission and seeing + signs where you expect spaces, the data used form encoding. Use decodeURIComponent(str.replace(/\+/g, ' ')) in JavaScript to handle both. This tool uses standard percent-encoding — a + in the input decodes as a literal plus, not a space.
Encoding a Full URL When You Should Encode a Component: The most common mistake is encoding an entire URL like https://api.example.com/search?q=hello world&lang=en as a single string, which encodes the structural characters (://?=&) as well as the values. The correct approach is to encode only the query parameter values and then assemble the URL: base + '?q=' + encodeURIComponent('hello world') + '&lang=' + encodeURIComponent('en'). Use this tool for encoding individual component values, not complete URLs — unless you genuinely need to embed a full URL as a parameter value inside another URL, which is a different use case where encoding the entire URL is correct.
Using encodeURI() instead of encodeURIComponent() when encoding query parameter values in JavaScript
Fix: encodeURI() is designed to encode a complete URL while preserving the characters that serve as URL structure separators: : / ? # & = + @. It does not encode these characters because they are assumed to already be in their correct structural positions. If you use encodeURI() to encode a query parameter value that contains an & or =, those characters will not be encoded, and the & will be misread as a parameter separator breaking your URL. encodeURIComponent() is the correct function for encoding query parameter names and values — it encodes everything that is not a letter, digit, or one of - _ . ! ~ * ' ( ). The rule is simple: always use encodeURIComponent() for parameter values, never encodeURI().
Forgetting to encode query parameters that come from user input
Fix: A search box, a form field, a file name picker — any user-provided value that ends up in a URL must be encoded before being appended to the URL string. A user typing 'cats & dogs' into a search box, then the application building the URL as '/search?q=' + userInput, produces a broken URL: /search?q=cats & dogs where the & is interpreted as the start of a second parameter. The query string the server receives is q=cats with a separate parameter called dogs. Encode every user-provided value before URL concatenation: '/search?q=' + encodeURIComponent(userInput). This is also a security concern — failing to encode user input in URLs is a vector for URL injection attacks.
Decoding a URL from logs and treating the decoded value as safe for display without further sanitization
Fix: Decoded URL parameter values from logs or request data are user-controlled strings. An attacker can put anything into a URL parameter — including HTML tags, script injection attempts, or SQL fragments — and it will appear decoded and seemingly innocent in your log analysis. Decoding a URL to understand what a request contained is fine for debugging. But if you then take that decoded value and render it in a web interface, insert it into a database query, or pass it to a shell command without additional validation and sanitization, you have introduced a security vulnerability. Decoding a URL does not make its content safe — it makes it readable. Sanitize separately.
Building redirect URLs without encoding the destination URL as a query parameter
Fix: A common pattern is a login redirect: after login, send the user to the page they originally requested. The URL looks like /login?redirect=https://app.example.com/dashboard. The problem is that https://app.example.com/dashboard contains a colon, slashes, and potentially query parameters — all of which need to be encoded when embedded as a query parameter value. Without encoding, the redirect URL looks like /login?redirect=https://app.example.com/dashboard?section=profile&tab=settings, where the ?section=profile is interpreted as a second parameter of the /login request, not as part of the redirect destination. Encode the destination: '/login?redirect=' + encodeURIComponent('https://app.example.com/dashboard?section=profile&tab=settings').
Assuming all servers decode the same way and at the same point in the request processing chain
Fix: Different servers and frameworks decode URL parameters at different points and with different behaviors. Express.js in Node.js decodes req.query parameters automatically using decodeURIComponent — you receive the decoded value. Flask in Python decodes request.args automatically. But if you read the raw query string (request.query_string in Flask, req.url in Node.js) and parse it yourself, you get the still-encoded value. Some reverse proxies decode URLs before forwarding them, some do not. In a debugging session, a value might appear decoded in your application code but still encoded in the proxy log for the same request. Know which layer you are reading from when comparing encoded and decoded forms — and always test the actual value your code receives, not what you expect it receives.
Git Cheatsheet
Quick reference guide for essential Git commands, branching workflows, remote repositories, stashing, and rollbacks.
Regex Cheatsheet
Interactive guide to Regex anchors, character classes, quantifiers, lookarounds, capturing groups, and search flags.
HTTP Headers Cheatsheet
Complete guide to standard and security HTTP headers including Authorization, CORS control, caching policies, and CSP directives.
SQL Cheatsheet
Complete guide to SQL statements including SELECT queries, WHERE filters, aggregate functions, JOIN types, and DDL commands.
What characters are safe in a URL without encoding?
RFC 3986 defines the unreserved characters that can appear in a URL without encoding: the 26 uppercase and 26 lowercase letters (A-Z, a-z), the 10 digits (0-9), hyphen (-), underscore (_), period (.), and tilde (~). Everything else — spaces, @, #, $, %, ^, &, *, (, ), +, =, [, ], {, }, |, \, :, ;, ', ', <, >, comma, and all Unicode characters — must be percent-encoded when used as data in a URL rather than as structural delimiters. The characters /, ?, #, &, and = are reserved for URL structure and should also be encoded when they appear as literal characters within a component value.
Is URL encoding the same as Base64?
No, they are completely different mechanisms for completely different purposes. URL encoding (percent-encoding) replaces individual unsafe characters with %XX hex sequences — the encoded result is mostly readable text with occasional %XX sequences. Base64 encodes arbitrary binary data as a string of 64 printable characters — the result looks like a completely unreadable block of letters and numbers. Use URL encoding to make specific characters safe for inclusion in a URL. Use Base64 to represent binary data (images, files, binary protocols) as text. The Base64 output itself often needs URL encoding if included in a URL query parameter because Base64 uses +, /, and = which are URL-special characters — this is why URL-safe Base64 exists as a variant that replaces + with - and / with _.
Does it support Unicode characters?
Yes. Unicode characters are encoded as their UTF-8 byte sequences and each byte is percent-encoded. A character like é (U+00E9) has UTF-8 representation C3 A9, so it encodes as %C3%A9. The Euro sign € (U+20AC) has UTF-8 representation E2 82 AC and encodes as %E2%82%AC. Chinese, Arabic, and other non-Latin scripts are similarly encoded as multi-byte UTF-8 sequences. Decoding works in reverse — consecutive %XX sequences that form a valid UTF-8 byte sequence are decoded to the correct Unicode character. This is the behavior specified by RFC 3986 and implemented by all modern browsers and JavaScript's encodeURIComponent.
What is the difference between %20 and + for encoding spaces?
There are two conventions for encoding spaces in URLs and they are not interchangeable. In standard percent-encoding (RFC 3986), a space is encoded as %20. This is what encodeURIComponent() produces and what modern URLs use. In application/x-www-form-urlencoded format — the format used when an HTML form is submitted with method=POST or method=GET — spaces are encoded as + signs, a legacy from earlier internet standards. Web servers and frameworks that process form submissions decode + as space in the query string. If you are working with form submission data and see + where you expect a space, that is form encoding. If you see %20, that is standard percent-encoding. In JavaScript, decodeURIComponent() correctly decodes %20 as space but leaves + as a literal plus. To decode form-encoded data, use decodeURIComponent(str.replace(/\+/g, ' ')).
How do I encode a URL in JavaScript, Python, or Go?
In JavaScript: encodeURIComponent(value) for query parameter values and path segments (encodes everything except letters digits - _ . ! ~ * ' ( )). encodeURI(fullUrl) for encoding a complete URL while preserving structural characters. In Python: from urllib.parse import quote then quote(value) or quote(value, safe='') to encode everything. urllib.parse.urlencode({'key': 'value with spaces & symbols'}) for query strings. In Go: url.QueryEscape(value) for query parameter encoding or url.PathEscape(value) for path segment encoding. In Ruby: URI.encode_www_form_component(value) or CGI.escape(value). In PHP: urlencode(value) for form-style encoding (spaces as +) or rawurlencode(value) for RFC 3986 encoding (spaces as %20).
Why does my encoded URL look different from what the browser shows?
Modern browsers display percent-encoded URLs in their address bar with some characters decoded for readability — they show the Unicode characters rather than the %XX sequences for characters that are safe to display. So a URL with %E2%82%AC in the actual request might appear as € in the address bar. The underlying request still uses the encoded form. Additionally, browsers may normalize URLs differently — they lowercase the scheme and hostname, remove default ports, normalize path separators, and may decode some percent-encoded characters that are actually safe. If your encoded URL differs from what you see in the browser, the browser may have decoded or normalized it. The network-level request (visible in DevTools under Network) shows the actual encoded URL that was sent.
What happens if I decode a URL that has not been encoded?
If the input has no %XX sequences, the decoder returns the input unchanged — there is nothing to decode. If the input has some valid %XX sequences and some bare % signs that are not part of a percent-encoded sequence, the behavior depends on the implementation. This tool handles it gracefully by decoding the valid sequences and leaving malformed % sequences as-is. In JavaScript, decodeURIComponent() throws a URIError exception on malformed input. decodeURI() is slightly more lenient. If you receive a URL that might be partially encoded and needs to be decoded safely in JavaScript, wrap the call in try/catch and handle the error case. In practice, if a URL decodes unexpectedly, the input may not have been URL-encoded to begin with — it may be Base64-encoded, HTML-entity encoded, or just plain text.
Should I encode the entire URL or just specific parts?
Only encode the data components — query parameter names and values, path segment values, and fragment identifiers. Never encode the structural parts of the URL (the scheme, host, path separators, ? and & delimiters, or = signs between parameter names and values). The correct approach when building a URL from components: start with the base URL as a string, then for each query parameter, URL-encode the name with encodeURIComponent(name) and the value with encodeURIComponent(value), then join them with = and connect multiple parameters with &. Using this tool to encode the value of a single parameter before pasting it into a larger URL is the right workflow. Using this tool to encode a complete URL and then use the result as a URL is the wrong workflow — unless you are embedding that entire URL as a parameter value inside another URL.
What is URL Encoding and Decoding Explained: Complete Guide 2026
What is URL Encoding and Decoding Explained: Complete Guide 2026. Learn how URL encoding works, encodeURI vs encodeURIComponent, when to encode, common mistakes, and real-world best practices.
URL Encoding Mistakes That Break Your Applications – Security & Technical Deep Dive (2026)
URL Encoding Mistakes That Break Your Applications – Security & Technical Deep Dive (2026). Learn common percent-encoding errors, encodeURI vs encodeURIComponent, double encoding, open redirects, parameter pollution, and secure URL construction best practices.
How to Optimize Website Performance Using Minification Tools (Complete Guide 2026)
How to optimize website performance using minification tools. Learn CSS, JS, HTML minification, real impact, best practices, and SEO benefits in 2026.
Recent Activity
No recent activity