URL Decoder Encoder Free Tool

Enter the text that you wish to encode or decode:

About URL Decoder Encoder

What This Tool Actually Does

The URL Decoder Encoder on this page is a server-side utility that takes whatever text you type into the box above and runs it through two PHP functions at the same time. Those functions are urlencode() and urldecode(). You get both results on the next page, side by side, in two separate textareas labeled "Encoded URL" and "Decoded URL." There is no mode switch, no dropdown, no checkbox. The tool simply shows you both transformations of your single input, and you read the box that matches the job you came here to do.

This design is unusual among the many encoding tools scattered across the web. Most similar utilities force you to choose between encoding and decoding before you submit. This one sends your text to the server once, and the server applies both functions in the same request. If your input is plain text, the Encoded box is the one you want. If your input is already percent-encoded, the Decoded box is the one you want. If your input is ordinary text with no special characters, both boxes will look nearly identical.

The tool lives in the Converter Tools category of this site. It sits alongside other small utilities that each do one narrow job. There is no account system, no login wall, and no request history. The page reloads when you submit, because the actual work happens on the server, not in your browser. That distinction affects how the tool interprets your input, and the earlier description of this page was incorrect.

You can paste in a single word, a sentence with spaces, a string full of ampersands and equals signs, or a text that is already encoded. The tool does not care. It treats everything as a plain string of characters and applies the same two functions to the whole thing. It does not look at your text and guess whether it is a URL, a query string, or a fragment of a larger document. It has no opinion about what your text means. It only transforms characters according to a fixed rule set.

That rule set explains nearly every result you will see. The encoding flavour used here is the one defined for HTML form submission, technically called application/x-www-form-urlencoded. In that flavour, a space becomes a plus sign. Every character except letters, digits, the hyphen, the underscore, and the dot becomes a percent sign followed by two hexadecimal digits. That means slashes, colons, question marks, equals signs, ampersands, tildes, and many other punctuation marks all get escaped. Non-ASCII characters are first converted to their UTF-8 byte sequences and then each byte is escaped. The decoding function reverses all of that, turning plus signs back into spaces and each percent-encoded sequence back into its byte.

The live test run for this rewrite used an input with spaces, an ampersand, accented characters, a slash, a question mark, and an equals sign. The Encoded box returned the fully escaped version of that string, with every space turned into a plus sign and every special character turned into its percent-encoded form. The Decoded box returned the input unchanged, because nothing in it was encoded. That single example shows the space to plus conversion, the escaping of the ampersand, the UTF-8 treatment of the accented characters, and the escaping of the slash, question mark, and equals signs.

A second live test used an input that was already partially encoded. The Encoded box returned a double-encoded version of that input, and the Decoded box returned the human-readable text. The tool encodes spaces as plus signs. The percent signs in the input were themselves encoded, turning each percent-encoded space into a double-encoded version of itself. That is the double-encoding effect. The Decoded box, meanwhile, converted the percent-encoded space sequences into spaces, turned the percent-encoded plus into a literal plus sign, turned the percent-encoded ampersand into an ampersand, and turned the bare plus into a space.

A third live test used the simple input a+b. The Encoded box returned a%2Bb, because a literal plus sign is not in the safe set and must be escaped. The Decoded box returned a b, because a plus sign in encoded text means a space. The third test shows the asymmetry at the heart of this tool. The same character, a plus sign, is treated completely differently depending on which direction you are looking.

How to Use This Tool

1. Open the tool page. Find the input box above this article and make sure you are on the URL Decoder Encoder page of this site.
2. Type or paste your text. Enter the string you want to transform into the textarea labeled "Enter the text that you wish to encode or decode."
3. Submit the form. Press the Submit button. The browser will refuse to send an empty box, so make sure you have typed something.
4. Read the Encoded URL box. If your input was plain text, this box shows the percent-encoded version that is safe to place inside a query parameter.
5. Read the Decoded URL box. If your input was already encoded, this box shows the human-readable text that the encoding represents.
6. Use the Try New Document button. When you want to run another transformation, click this button to return to a fresh form and start again.

The workflow is a single round trip. You submit, the page reloads, and the results appear below the heading. There is no live preview as you type, no button to swap the two result boxes, and no way to copy a result with one click. You select the text in the relevant textarea and copy it yourself.

Which box you read depends entirely on what you started with. If you typed a normal sentence with spaces and punctuation, the Encoded box is your answer. If you pasted a string that already contains percent signs, the Decoded box is your answer. If you pasted a string that contains a mix of encoded and plain text, you will need to think about which transformation you actually want, because the tool applies both to the whole input without asking.

The page reloads on every run. That is a consequence of the server-side design. Your browser sends the text to the server, the server runs the two PHP functions, and the server sends back a fresh HTML page with the results. Nothing about this happens inside your browser's JavaScript engine. You can verify this yourself by watching the address bar during submission or by disabling JavaScript entirely and repeating the test.

Correcting the Old Description of This Tool

The previous version of this page described the tool in ways that do not match its actual behaviour. The corrections are now in place, and returning visitors can see what changed and why other pages may describe the tool differently.

The old copy claimed that spaces are converted to the percent-encoded form used in URI paths. That is wrong for this tool. The PHP urlencode() function uses the form-encoding flavour, in which a space becomes a plus sign. You will never see the percent-encoded form used in URI paths in the Encoded box from this tool, no matter what you type. If you need the percent-encoded form used in URI paths for a path segment or for URI syntax compliance, this is not the tool for that job. The old copy also presented a false choice between encodeURI, encodeURIComponent, and form encoding as if this tool let you pick among them. It does not. The tool has exactly one encoding function, PHP's urlencode(), and you get no options.

The old copy described the tool as a plain client-side text transformation. That is also wrong. The transformation happens on the server, in PHP, during a POST request. Your text leaves your browser, travels to the server, and comes back in a reloaded page. This distinction matters for privacy, for offline use, and for understanding why the page reloads. A purely client-side tool would work with no network request at all. This one cannot.

The old FAQ answered a question about why spaces sometimes become the percent-encoded form used in URI paths and sometimes become a plus sign by implying that both outcomes were possible here. This tool always uses the plus sign for spaces. The percent-encoded form used in URI paths belongs to a different encoding standard, the URI syntax standard, which this tool does not implement. The old copy also failed to mention that both directions are shown at once, and it did not warn about the double-encoding effect that appears when you feed already-encoded text into the Encoded box.

The corrected description on this page reflects what the code actually does. The tool runs urlencode() and urldecode() on your input and shows both results. It has no other modes. It has no options. It has no awareness of what your text means. Those are the facts, and the rest of this article explains their practical consequences.

The Two Encodings and Why the Plus Sign Matters

The confusion between the percent-encoded form used in URI paths and the plus sign is the most common source of misunderstanding in URL encoding, and this tool sits right in the middle of it. The two forms come from two different standards that people routinely mix up.

The first standard is the one used for HTML form submission. When a browser submits a form with method="POST" and enctype="application/x-www-form-urlencoded", it encodes spaces as plus signs. This behaviour dates back to the earliest days of the web and is specified in the HTML standard. PHP's urlencode() function implements exactly this flavour, which is why it turns spaces into plus signs.

The second standard is the URI syntax standard, which defines the syntax of URIs themselves. In that standard, spaces are not allowed at all and must be encoded as the percent-encoded form used in URI paths. The rawurlencode() function in PHP implements this flavour. JavaScript's encodeURIComponent() also uses the percent-encoded form used in URI paths for spaces. When you see a URL in your browser's address bar with the percent-encoded form used in URI paths in it, that is URI syntax encoding applied to a path segment.

This tool implements only the first flavour. The form-encoding flavour. The application/x-www-form-urlencoded flavour. That is what urlencode() does, and this tool has no switch to change it. If you need the URI syntax form, you need a different tool or a different function in your own code.

The tool always uses form encoding. If you are building a query string and need to put a value inside a parameter, the plus sign is correct and this tool's Encoded box gives you what you need. If you are constructing a URL path or dealing with a full address, you need the percent-encoded form used in URI paths, and this tool cannot produce it.

The live tests confirm this behaviour. The input with spaces and accented characters produced an output where every space became a plus sign. The slash, question mark, equals signs, and ampersand all became percent-encoded sequences. The accented characters became UTF-8 bytes. Nothing in that output contains a single instance of the percent-encoded form used in URI paths.

You must know which encoding standard your receiving system expects. A server-side script using $_GET in PHP will decode plus signs as spaces correctly. A JavaScript routine using decodeURIComponent() will not, because that function expects the percent-encoded form used in URI paths. Mismatching the two is a classic source of bugs where a space arrives as a literal plus sign in your application logic.

The Full URL Pitfall

One of the most common mistakes people make with this tool is pasting an entire URL into the input box and expecting the Encoded result to be a usable encoded version of that address. The tool will happily encode the whole thing, but the result is probably not what you want.

Consider a URL like https://example.com/page?name=john. When you paste that into this tool and read the Encoded box, you get an output where the scheme, the colon, the slashes, and the question mark have all been escaped. This output is only correct if you intend to place that entire URL as a value inside another query parameter, like ?redirect=https%3A%2F%2Fexample.com%2Fpage%3Fname%3Djohn. In that context, the encoding is exactly right, because the inner URL is just a string value and its special characters must not be interpreted by the outer query string parser.

If your goal is to produce an encoded version of the URL that a browser can still navigate to, this output is wrong. A browser cannot fetch a URL where the scheme has been escaped. The scheme must remain unescaped for the URL to be recognized. This tool does not know that. It has no component awareness, meaning it cannot tell a scheme from a path from a query parameter. It treats the entire input as a single opaque string and encodes every character that is not in its safe set.

The same problem applies to the Decoded box in reverse. If you paste a fully encoded URL and decode it, you get the original URL back, which is useful. But if you paste a partially encoded URL, one where only some characters have been escaped, the Decoded box will decode those and leave the rest alone, producing a mixed result that may not be valid for any purpose.

This tool encodes and decodes values. It is for the content that goes inside a URL, not for the URL itself. When you build a query string in PHP, you call urlencode() on each parameter value, not on the whole URL. This tool shows you what that function does to your value, nothing more.

The live test with the accented input demonstrates this clearly. The slash after the accented word was escaped, and the question mark was escaped. If you were building a URL by hand and wanted those characters to act as separators, this encoding would break your URL. If you were placing the whole string inside a single parameter, the encoding is exactly what you need.

Double Encoding and What It Means

Feeding already-encoded text into this tool produces results that surprise many first-time users. The Encoded box will encode the percent signs themselves, turning each percent sign into a percent-encoded version of itself. This is the double-encoding effect, and it is not a bug. It is the mathematically correct behaviour of applying an encoding function to text that is already in encoded form.

The live test with the partially encoded input produced a double-encoded version of that input in the Encoded box. Each instance of the percent-encoded form used in URI paths became a double-encoded version of itself. Each percent-encoded plus became a double-encoded version of itself. Each percent-encoded ampersand became a double-encoded version of itself. The bare plus sign became a percent-encoded plus. If you were to run that output through the encoder again, you would get yet another layer of percent signs. This process can continue indefinitely, which is why you sometimes see URLs with multiple layers of encoding in the wild.

Double encoding is usually a mistake in real applications. It happens when a developer encodes a value that has already been encoded, often because a framework or a middleware layer encodes automatically and the developer encodes again on top of that. The result is a value that decodes to something that still contains percent signs, which then needs a second decode to become the original text.

This tool shows exactly what double encoding does to your data. If you suspect that a value in your application has been encoded twice, you can paste it into the Decoded box once to remove one layer, then paste the result back in to remove the second layer. Two round trips through the Decoded box will fully reverse two layers of encoding.

The Decoded box also has a subtle behaviour that catches people. A literal plus sign in your input becomes a space in the Decoded output. This is correct form-encoding behaviour, because in encoded text a plus sign means a space. But if you have plain text that contains a real plus sign, like a phone number written with a country code, decoding it will turn that plus sign into a space. The tool cannot distinguish between a plus sign that means "space" and a plus sign that is literally part of your data. In encoded text, the plus sign always means space, and a literal plus sign must be encoded as a percent-encoded plus.

The third live test confirms this. The input a+b produced a b in the Decoded box. The plus sign was interpreted as a space. If you wanted to preserve the plus sign through a decode operation, you would need to encode it first as a percent-encoded plus, and then decode that, which would give you back your literal plus sign.

What the Tool Lacks

Using any tool well requires understanding its limits. This URL Decoder Encoder does a specific job with a specific encoding flavour, and it has clear boundaries that you should understand before you rely on it for serious work.

The tool has no raw mode. It cannot produce the percent-encoded form used in URI paths for spaces, because it only implements the form-encoding flavor of urlencode(). If your target system expects URI syntax encoding, you need rawurlencode(), and this tool does not offer it. You will need to use a different utility or write the encoding yourself in your own code.

The tool has no component awareness. It does not know whether the text you pasted is a scheme, a hostname, a path, a query string, or a fragment. It treats the entire input as one flat string. This means it cannot make smart decisions like leaving the scheme part of a URL unescaped while encoding only the query parameter values. A component-aware encoder would need to parse the URL structure first. This tool does no parsing at all.

The tool has no Punycode or IDN handling. If you paste a domain name with non-ASCII characters, like bücher.example, the tool will percent-encode the UTF-8 bytes of those characters, but it will not convert the domain to its Punycode form, which is what the Domain Name System actually needs. Punycode conversion is a completely different algorithm, and this tool does not implement it.

The tool does no HTML entity encoding. It will not turn an ampersand into an HTML entity. That is a separate encoding system for HTML documents, and confusing it with URL encoding is a common beginner mistake. This tool only does URL encoding, and only the form-encoding flavour of it.

The tool does no Base64 encoding. Base64 is yet another encoding system, used for binary data in text form, and it has nothing to do with URL percent encoding. If you need Base64, this is not the tool.

The tool does not validate your input. You can type anything, including strings that are not valid URLs, not valid query strings, and not valid encoded text. The tool will process them anyway. Invalid percent sequences, like a lone percent sign or a percent sign followed by non-hexadecimal characters, are left as they are by the Decoded box. There is no error message, because there is no validation to trigger one.

The output page has no copy button. You select the text in the result textarea and copy it with your browser's normal copy command. There is no swap button to exchange the contents of the two boxes, and no character count to tell you how long your result is. The page is minimal by design.

Server-Side Behaviour and Rate Limits

This tool runs entirely on the server. When you submit the form, your browser sends a POST request to the server, and the server responds with a new page containing your results. This has several consequences you should know about.

The first consequence is that your text leaves your browser. If you are encoding sensitive data, you should be aware that the text travels over the network to this server and back. A purely client-side tool would keep your data in your browser, but this tool cannot work that way. The transformation happens in PHP on the server.

The second consequence is that the page reloads on every submission. There is no Ajax, no asynchronous JavaScript, no live updating. You click Submit, the browser navigates to the output page, and you see your results. To run another transformation, you use the Try New Document button, which returns you to a fresh input form.

The third consequence is that nothing is stored. The tool does not save your input, does not log your results, and does not fetch any URL on your behalf. The text is processed and the response page is generated, and then the transaction is over. There is no database write and no session state to worry about.

There is no CAPTCHA on this tool, and there is no tool-specific request limit. However, this site applies a shared throttle to every page on the domain. If a single visitor address makes more than roughly fifteen requests within one second, that address receives a 503 error for the rest of the day. This is a site-wide protection against abusive traffic, not a restriction aimed at this tool specifically. Normal use, submitting a form a few times in a row, will never come close to this threshold.

Do not build automated scripts that hammer this page dozens of times per second. For manual use, typing or pasting text and clicking Submit a handful of times, the rate limit is irrelevant. The tool is designed for occasional interactive use, not for bulk batch processing.

Reading the Results Correctly

The output page presents two textareas with headings above them. The first heading reads "Encoded URL" and the second reads "Decoded URL." Below both textareas is a button labeled "Try New Document." There is nothing else on the output page, no explanatory text, no examples, no hints. You are expected to know which box matters for your task.

Reading the Encoded box is appropriate when your input is plain text and you need the form-encoded version of it. This is the box you want when you are building a query string parameter value in PHP, when you are constructing a URL that will be processed by a server-side script, or when you want to see how PHP's urlencode() would transform a given string.

Reading the Decoded box is appropriate when your input is already percent-encoded and you want the original text back. This is the box you want when you are inspecting a URL's query string, when you are debugging why a parameter value looks garbled, or when you have an encoded string from a log file and you need to see what it actually says.

The two boxes are independent. The contents of the Encoded box are not derived from the contents of the Decoded box. Both are computed directly from your original input. If your input contains no characters that need encoding, the Encoded box will show the input unchanged. If your input contains no percent signs and no plus signs, the Decoded box will also show the input unchanged. In those cases, both boxes look the same, which can be confusing until you realize that the identity transformation is a valid outcome for both functions.

A common workflow is to use the Decoded box first to clean up an encoded string, then copy the result into the input box and read the Encoded box to see how the clean text would be encoded for a different context. This two-step process can help you understand how a particular string behaves under both transformations.

The live tests provide concrete reference points. The input with accented characters decoded to itself, because nothing in it was encoded. The partially encoded input decoded to a string with spaces, a literal plus sign, and an ampersand, which shows how each encoded sequence maps back to its original character. The input a+b decoded to a b, which shows the plus to space rule in its simplest form.

Related Tools

If you need to encode or decode text for reasons other than URL query strings, the other converter tools on this site may serve you better. The MD5 Generator produces a 128-bit hash of your input text, which is useful for checksums, password storage in legacy systems, and verifying file integrity. The Text to Binary Converter turns your characters into their binary representations, which is a different kind of transformation entirely and useful for learning how computers store text.

If your interest is in server configuration rather than text transformation, the Htaccess URL Rewrite tool works with Apache's mod_rewrite module and helps you build rules that map incoming URLs to different destinations. That tool operates at the level of URL structure and routing, which is a completely different layer from the character-level encoding this page handles.

Each of these tools covers a distinct need. The MD5 Generator and Text to Binary Converter are for character and data transformations. The Htaccess URL Rewrite tool is for web server behaviour. This URL Decoder Encoder is specifically for percent encoding and decoding in the form-encoding flavour.

Encoding for PHP and Query Strings

PHP developers will recognize the behaviour of this tool immediately, because it is exactly what the urlencode() and urldecode() functions do. When you build a query string in PHP, you typically write something like 'name=' . urlencode($name). The function ensures that spaces become plus signs, ampersands become percent-encoded ampersands, and any other special characters are safely escaped so that they do not break the query string's syntax.

This tool lets you preview what urlencode() will do to a given string before you write your PHP code. Type the string into the input box, submit, and read the Encoded box. The output is precisely what PHP would produce. This is useful for testing, for debugging, and for understanding why a particular value arrives at your server in a particular form.

The decoding direction works for PHP developers. When you receive a query string and read $_GET['name'] in PHP, the value has already been decoded by the server. But if you are reading a raw query string from a log file or from a URL that was not processed by PHP's automatic decoding, you may need to apply urldecode() yourself. This tool shows you what that function will do.

The form-encoding flavour is baked into PHP's web model. When a browser submits an HTML form with the default encoding type, PHP decodes the incoming data automatically. The plus signs become spaces, and the percent sequences become their original characters. This tool mirrors that behaviour exactly, because it uses the same functions.

There is a common misconception that PHP's urlencode() is somehow deprecated or wrong because it uses plus signs instead of the percent-encoded form used in URI paths. It is neither. The function is correct for its intended purpose, which is encoding data for form submission and query strings. The confusion arises when developers use urlencode() for path segments, where URI syntax rules apply and the percent-encoded form used in URI paths is required. This tool will happily encode a path segment for you, but the result will use plus signs, which is wrong for that context.

UTF-8 and International Characters

The treatment of non-ASCII characters is one of the most useful features of this tool, and one of the most commonly misunderstood. When you type an accented character like é into the input box, the Encoded box shows a percent-encoded pair of bytes. Those two percent-encoded bytes are the UTF-8 representation of the character é.

UTF-8 is the dominant character encoding on the web, used by the vast majority of websites and supported by every modern browser. In UTF-8, the character é is represented by two bytes. Percent encoding each byte gives you the percent-encoded form you see in the output. The live test with the accented word in the input produced exactly this result.

Characters outside the ASCII range, including accented Latin letters, Greek letters, Cyrillic letters, Chinese characters, emoji, and everything else in the Unicode standard, are all handled the same way. Each character is converted to its UTF-8 byte sequence, and each byte is then percent-encoded. A single emoji can become a long string of percent-encoded bytes, because emoji are represented by multiple bytes in UTF-8.

The Decoded box reverses this process. It reads each percent-encoded sequence, converts the two hexadecimal digits to a byte, and then interprets the resulting byte sequence as UTF-8. If the byte sequence is valid UTF-8, you get your original characters back. If it is not valid UTF-8, the behaviour depends on the server's configuration, and you may see replacement characters or garbled output.

Percent encoding is fundamentally a byte-level operation. The tool operates on bytes. The fact that you see readable characters in the Decoded box is a consequence of UTF-8 being the assumed interpretation of those bytes.

This matters for internationalized domain names. A domain like bücher.example contains a character that is not valid in the ASCII-only DNS system. The correct way to handle such domains is Punycode, which encodes the Unicode name into an ASCII-compatible form starting with xn--. This tool does not do Punycode. It will percent-encode the UTF-8 bytes of the accented character, but that is not what the DNS system needs. If you paste an internationalized domain into this tool, you will get percent encoding, not Punycode.

Common Use Cases and Worked Examples

The practical value of this tool becomes clear when you work through realistic scenarios. Consider a search form on a website. A user types a query like best pizza in new york into a search box. When the form is submitted, the browser encodes that query for the URL. The space between each word becomes a plus sign, giving you a string with plus signs between the words. This tool shows you exactly that transformation.

Now consider a URL parameter that contains a URL. A redirect parameter might look like ?next=https://example.com/dashboard?tab=reports. The inner URL contains colons, slashes, and a question mark, all of which would break the outer query string if left unescaped. Encoding the inner URL gives you a string where the colons, slashes, and question mark are all percent-encoded. This tool produces that output when you paste the inner URL into the input box.

Consider a debugging scenario. You see a URL in your server logs that contains a query parameter with percent-encoded sequences and a bare plus sign. You want to know what the user actually searched for. Paste the encoded value into this tool and read the Decoded box. You get a string with spaces, a literal plus sign, and an ampersand, which tells you the user typed that exact text with a literal plus sign in their query.

Consider a data cleaning task. You have a list of values that were double-encoded by a buggy application. Each value looks like a double-encoded space where there should be a space. Paste one value into the Decoded box and you get a single-encoded version. Paste that result back in and you get the original text. Two passes through the Decoded box fully reverse the double encoding.

The tool is also useful for teaching. If you are explaining URL encoding to a colleague or a student, this tool shows both directions at once, which makes the symmetry and asymmetry of the two functions visible. The plus sign behaviour, the safe character set, the UTF-8 byte handling, and the double-encoding effect can all be demonstrated with a few simple inputs.

Limitations

Every tool has boundaries, and this one has several that you should understand before relying on it for production work. The most significant limitation is the lack of a raw mode. If you need the percent-encoded form used in URI paths for spaces, this tool will not give it to you. The PHP urlencode() function, which is the only encoder this tool uses, always emits plus signs for spaces.

The tool also lacks component awareness. It cannot tell the difference between a scheme, a host, a path, a query string, and a fragment. It treats your entire input as one flat string and applies the same encoding to every character. This means you cannot use it to encode only the query portion of a URL while leaving the rest intact. You must split the URL yourself, encode the parts you need, and reassemble it.

The tool has no Punycode support for internationalized domain names. It will percent-encode non-ASCII characters in a domain name, but the result will not be usable in the DNS system. If you need to convert an internationalized domain to its Punycode form, you need a dedicated Punycode converter.

The tool does not handle HTML entities. An ampersand in your input will be encoded as a percent-encoded ampersand for URL purposes, not as an HTML entity for HTML purposes. These are different encoding systems, and confusing them leads to garbled output in web pages.

The tool does no validation. You can submit any text, including strings that are not valid URLs, not valid encoded data, and not meaningful in any context. The tool will process them anyway. Invalid percent sequences in the Decoded box are left unchanged, so a lone percent sign in your input will still be a lone percent sign in your output.

The output page is minimal. There is no copy button, no swap button, and no character count. You must select the result text manually and copy it with your browser's commands. For frequent use, this can become tedious.

The tool processes one text per submission. There is no batch mode, no file upload, and no way to process multiple strings at once. Each transformation requires a separate form submission and page reload.

The rate limit applies to the whole site. If you make more than roughly fifteen requests from one address within a single second, that address is blocked for the rest of the day. This is unlikely to affect normal manual use, but it rules out any kind of automated batch processing.

This tool is best understood as a demonstration and debugging aid for PHP's urlencode() and urldecode() functions, not as a general-purpose URL utility. For the narrow job of seeing what those two functions do to a given string, it is accurate and complete. For broader URL manipulation tasks, you will need additional tools.

Frequently Asked Questions

Why does this tool use a plus sign for spaces instead of %20?

This tool uses PHP's urlencode() function, which implements the form-encoding flavour of URL encoding. In that flavour, a space becomes a plus sign. The percent-encoded form used in URI paths belongs to the URI syntax standard, which is implemented by PHP's rawurlencode() function. This tool has no mode switch, so you will always see plus signs for spaces in the Encoded box.

Why does my already-encoded text get double-encoded in the Encoded box?

The Encoded box applies urlencode() to your entire input, including any percent signs that are already there. Each percent sign becomes a percent-encoded percent sign, so a percent-encoded space in your input becomes a double-encoded version of itself in the output. This is correct behaviour for an encoding function, but it means you should only use the Encoded box on plain text, not on text that is already encoded.

Why does a literal plus sign in my text become a space in the Decoded box?

In form-encoded text, a plus sign means a space. The urldecode() function therefore converts every plus sign to a space. If your text contains a literal plus sign that you want to preserve, you must encode it as a percent-encoded plus first. The tool cannot distinguish between a plus sign that means space and a plus sign that is part of your data.

Can I encode a full URL with this tool?

You can paste a full URL into the input box, but the Encoded box will escape the scheme, slashes, and question mark, producing a string that starts with a percent-encoded scheme. That output is only correct if you want to place the entire URL as a value inside another query parameter. A browser cannot navigate to the encoded result directly.

Does this tool work in my browser without sending data to a server?

No. This tool is server-side. Your text is sent to the server in a POST request, processed by PHP, and returned in a reloaded page. Nothing is stored, but your text does travel over the network. A purely client-side tool would process the text in your browser with JavaScript, but this tool does not work that way.

What is the difference between this tool and an HTML entity encoder?

URL encoding and HTML entity encoding are completely different systems. URL encoding uses percent signs and hexadecimal digits to make text safe for URLs and query strings. HTML entity encoding uses sequences like & to make text safe for HTML documents. This tool only does URL encoding. If you need HTML entities for an ampersand in HTML, you need a different tool.