URL encoder

URL encoder is a free tool that converts a string into the form-encoded representation used in URL query parameters and other text-based web data.

What is URL encoding and why is it used?

URL encoding replaces characters that have a special meaning in a URL with a percent sign followed by hexadecimal digits. It allows text to pass through systems that expect a restricted set of characters.

For example, an ampersand separates query parameters, so an ampersand that belongs inside a value must be encoded as %26. Spaces need special handling too. This tool uses PHP's urlencode function, which converts a space to a plus sign.

Before: tea and cake

After: tea+and+cake

You may encounter URL-encoded text in:

• query strings submitted by web forms;
• data URIs containing text that cannot appear literally;
• links included in email messages;
• URL values stored in JSON payloads;
• redirect and callback parameters used by web applications;
• URLs associated with internationalised domains, although the domain name itself may require Punycode rather than percent encoding.

URL encoding is not encryption and provides no secrecy. Anyone who can see a percent-encoded URL value can decode it.

How do I use the URL encoder?

Enter the string that needs to be encoded, run the tool and read the converted value in the URL encoded result field. Encode the value itself rather than surrounding quotation marks or explanatory text.

The work takes place on the server. Your input travels to the server over HTTPS and is not stored. Even so, avoid putting passwords, session tokens or private personal data into URLs because web addresses can appear in browser history, analytics systems and server logs.

To reverse the operation, use the URL decoder. A correctly decoded value should match the original text, provided that the same character encoding and form-encoding rules are used in both directions.

Should I encode a whole URL or only the parameter value?

You should normally encode each parameter value, not the complete URL. Encoding a whole address would also replace structural characters such as the colon, forward slashes, question mark and equals sign.

Suppose a search value is green tea & coffee. Its encoded form is green+tea+%26+coffee, which can be placed after a parameter name. Encoding the full address would obscure the separators that a browser needs to recognise its scheme, host, path and query string.

This tool's use of urlencode is well suited to HTML form-style query parameters. Some APIs and path segments follow RFC 3986 conventions instead, where a space is written as %20 rather than +. Check whether the receiving system expects form encoding with + or RFC 3986-style %20.

Worked URL-encoding examples

ASCII letters and digits remain readable. Spaces become plus signs, while reserved punctuation and non-ASCII text are represented by encoded bytes.

• hello world becomes hello+world.
• tea & cake becomes tea+%26+cake.
• email=test@example.com becomes email%3Dtest%40example.com.
• 100% ready becomes 100%25+ready.
• café becomes caf%C3%A9 when the source text uses UTF-8.

Accented letters and non-Latin scripts are first represented as bytes by a character encoding, usually UTF-8 on the web. Each byte outside the permitted set then receives its own percent escape. This means one visible character may produce several groups beginning with %.

Numbers need no special treatment. Empty input produces no encoded content. Very long input can grow considerably because each encoded byte occupies three characters.

Why does URL decoding fail or produce gibberish?

Decoding usually fails because the input was encoded under different rules, was encoded more than once, or does not represent text in the expected character set.

• Different space handling. A form decoder treats + as a space, while a strict percent decoder may leave it as a plus sign.
• Double encoding. The percent sign in %26 can itself become %25, producing %2526. One decoding pass then returns %26 rather than the original ampersand.
• Wrong character encoding. UTF-8 bytes decoded as another character set can produce replacement symbols or garbled letters.
• Binary rather than text data. Decoded bytes may be an image, archive or other file, so displaying them as text produces gibberish.
• Wrong format or alphabet. URL-safe Base64, standard Base64 and percent encoding are different formats. Applying a URL decoder to Base64 text will not recover the intended value.

URL encoding has no padding characters. If a decoder reports missing padding, the input is probably Base64 or another padded format rather than percent-encoded text.

Frequently asked questions

Are upper-case and lower-case percent escapes equivalent?

Yes. Hexadecimal letters in percent escapes are case-insensitive, so %2F and %2f both represent a forward slash. Upper-case hexadecimal digits are recommended for consistent representation.

Can URL encoding convert an international domain name?

No. Domain labels such as a name containing é normally require Internationalised Domain Name processing and an ASCII Punycode form beginning with xn--. Percent encoding is used for other URL components and should not be treated as a substitute for that conversion.

What happens to line breaks and tabs?

Tabs and line-break bytes are percent encoded because they cannot appear literally in a conventional URL value. A tab is commonly represented as %09, while line endings depend on whether the source uses LF or CRLF characters.

Why does an encoded URL still fail when pasted into an application?

The application may expect a raw value and perform its own encoding, causing double encoding. It may also reject the URL because of an overall length limit or because a reserved character was encoded in a structural part of the address. Check which individual component the application asks for before encoding it.

Is encoded query-string data safe to share?

No. URL percent-encoding only changes the representation, and browsers and developer tools can reveal the original value. Before sharing a link, inspect its query parameters for email addresses, account references, access tokens and other data that should not be disclosed.