Enter the text that you wish to encode or decode:
Use this free URL Encoder/Decoder to convert text into an application/x-www-form-urlencoded string or turn an encoded string back into readable text. Paste one string into the input field and run the tool. The result page displays both the encoded and decoded outputs generated from your submission.
This page uses PHP URL-encoding behavior. When encoding, characters that cannot remain unchanged are represented in a form suitable for query-string data. Spaces become plus signs, and many special characters become a percent sign followed by two hexadecimal digits. When decoding, percent sequences are restored and plus signs become spaces.
URLs use certain characters to separate their components. For example, ? begins a query string, & separates parameters, = separates a parameter name from its value, and # introduces a fragment. If one of these characters is intended to be data rather than syntax, it may need to be encoded.
Percent-encoding represents a byte using % followed by two hexadecimal characters. For example, a hash sign can be represented as %23, an ampersand as %26, and a question mark as %3F. The precise characters that should be encoded depend on where the data will appear inside a URL.
The tool processes the submitted text as one string. It does not validate whether the result is a complete working URL, send the URL to a server, test a destination or save a history of your conversions.
If the submitted text is:
blue shoes
The encoded result produced by this tool is:
blue+shoes
If the submitted text is:
name=John & category=men
Its special characters and spaces are encoded so they can be treated as data rather than query-string separators. This is particularly useful when encoding an individual parameter value.
Decoding reverses supported URL-encoded sequences. For example:
blue+shoes becomes blue shoes.red%26black becomes red&black.page%3Fid%3D25 becomes page?id=25.PHP decoding treats a plus sign as a space. Therefore, if a literal plus sign is part of the original data, it should normally be encoded as %2B before decoding.
A space can appear as + in form-style query encoding or as %20 in general percent-encoding. This tool uses PHP urlencode(), which follows the form-style convention and encodes a space as +.
This distinction matters when comparing tools. A component encoder that follows RFC 3986 more directly may show %20 instead. Both forms can represent spaces in appropriate query-string contexts, but they are not interchangeable in every part of every URL.
Encoding an individual query value is different from encoding a complete URL. Suppose a destination contains this query:
https://example.com/search?q=red shoes&sort=new
The structural characters :, /, ?, = and & give the URL its meaning. Encoding the entire address as a single value will also encode those delimiters. That may be correct when the entire address is being placed inside another parameter, but it is not normally correct when you simply want to open the original URL.
For application development, encode each user-provided parameter value with a method appropriate to that component, then assemble the URL using the required separators. Do not repeatedly encode an already encoded value unless the receiving system specifically expects nested encoding.
Search phrases, product names and other values may contain spaces or reserved characters. Encoding prevents those characters from being confused with the separators used to construct the query string.
An application may place one complete URL inside a parameter such as return_url. In that context, encoding the nested address prevents its own query characters from interfering with the outer URL.
HTML form submissions commonly use application/x-www-form-urlencoded. PHP’s urlencode() behavior follows this style, including converting spaces to plus signs.
Decoding can make an encoded parameter easier to inspect during development. It helps reveal the text represented by percent sequences, but it does not establish whether the destination is trustworthy.
Letters, digits and a limited set of punctuation can remain unencoded in many URL components. Other characters may be reserved because they have structural meanings. Whether a character needs encoding depends on its context: a slash is meaningful in a path, an ampersand separates query parameters, and a hash sign begins a fragment.
There is no single instruction to encode every visible character in every URL. Identify the component being built, use the correct encoder for that component and avoid changing delimiters that the receiver needs to interpret.
Non-ASCII characters are normally represented through their encoded bytes. A single visible character can produce several percent sequences because its UTF-8 representation may contain more than one byte.
Both ends of an application should agree on character encoding. If text is converted using one character set and interpreted using another, the decoded result may appear corrupted. This tool returns the transformation performed by PHP; it cannot repair text that was already encoded with the wrong character set.
Encoded data is not secret. Anyone can decode it, and browsers or servers routinely do so. Do not place passwords, private tokens, personal data or confidential information in a URL merely because the value looks unreadable after encoding. URLs may be stored in browser history, server logs, analytics systems and referrer information.
Use HTTPS to protect data in transit and use appropriate authentication and secure storage for sensitive information. URL encoding provides formatting, not confidentiality.
Encoding a value does not automatically prevent cross-site scripting, SQL injection, command injection or other attacks. Each output context requires its own protection. HTML output needs correct HTML escaping, database queries need parameterized statements, and commands should avoid untrusted input or use safe APIs.
When decoded data is later inserted into HTML, JavaScript, SQL or another interpreter, validate it and apply the protection required by that destination. Never treat decoding as proof that a value is safe.
If % in an existing sequence is encoded again, %20 may become %2520. Decode or encode only at the layer where it is required, and keep track of whether the incoming value has already been processed.
An application may decode request data automatically. Applying another decoding operation can unexpectedly transform literal percent sequences or plus signs. Check the framework behavior before decoding again.
When only a search phrase needs encoding, encoding the whole address also changes its separators. Encode the component, not the entire URL, unless the full URL is itself being transmitted as data.
With form-style decoding, + becomes a space. Use %2B when the original value must contain an actual plus sign.
It uses PHP urlencode() behavior. Spaces become plus signs, while many other characters are represented through percent sequences.
It uses PHP urldecode() behavior. Supported percent sequences are decoded and plus signs become spaces.
The tool processes the submitted content as one text string. It does not parse a list and create a separate report for every line.
No. Encoding is a formatting mechanism, not protection against malicious input. Use validation and context-specific security controls in your application.
No. Encoded text can be decoded easily. Never consider URL encoding a privacy or encryption feature.
PHP urldecode() interprets plus signs as spaces. A literal plus should be represented as %2B.
Usually you should encode only the relevant component or parameter value. Encode a full URL when it is being carried as data inside another value and the receiving application expects that format.
The URL Encoder/Decoder makes it easy to inspect how one string changes under PHP’s form-style URL encoding and decoding rules. Use the output carefully, preserve the structural characters required by complete URLs and remember that encoding solves a formatting problem—not a security or privacy problem.