Encode plain text and special characters for safe use in URLs and query strings, or decode percent-encoded URLs back to readable text. Runs entirely in your browser — nothing is sent to any server.
URL encoding, officially called percent-encoding, is a mechanism for representing characters that are not allowed or have special meaning in URLs. The HTTP specification (RFC 3986) defines a set of characters that are safe to use in a URL — these are letters, digits, and a small set of punctuation marks (-, _, ., ~). Every other character must be encoded as a percent sign followed by two hexadecimal digits representing the character's UTF-8 byte value.
For example, a space character has the UTF-8 byte value 32 (decimal), which is 20 in hexadecimal, so it is encoded as %20. An at-sign (@) becomes %40. An ampersand (&) — which has special meaning as a query string separator — becomes %26 when it appears in a parameter value. This encoding allows arbitrary text to be safely transported in a URL without being misinterpreted by browsers, servers, or intermediaries.
There are two levels of URL encoding that developers use for different purposes. encodeURI() encodes a complete URL, preserving characters that have structural meaning in URLs — it leaves characters like /, ?, &, =, #, and : unencoded because they are valid URL components. Use this when encoding an entire URL that you want to remain functional.
encodeURIComponent() encodes a single URL component such as a query parameter value, and encodes all special characters including /, ?, &, =, and #. Use this when encoding parameter values to prevent them from being interpreted as URL structure. For example, if a search query contains an ampersand, using encodeURIComponent() ensures the ampersand is encoded as %26 and not treated as a parameter separator. This tool exposes both modes.
URL encoding is required in many web development scenarios. When building query strings dynamically, parameter values must be encoded to prevent injection and parsing errors. When redirecting users to a URL that is itself a parameter value (a common pattern in OAuth flows), the entire redirect URL must be component-encoded. When constructing API requests with search terms, filters, or other user input, all values must be encoded before being concatenated into the URL. When working with internationalized domain names or paths that contain non-ASCII characters, encoding ensures correct transmission across systems that may only support ASCII.
Both + and %20 represent a space in URLs, but they are used in different contexts. In the query string portion of a URL (after the ?), the application/x-www-form-urlencoded format — used by HTML forms — represents spaces as +. RFC 3986 percent-encoding uses %20. Modern APIs overwhelmingly expect %20. If you are working with form submissions, your server framework will handle + correctly, but for manually constructed URLs and API calls, %20 is safer and more portable.
POST https://api.toolpad.in/api/v1/datatools/encode/url — body: {"input":"your text"}
POST https://api.toolpad.in/api/v1/datatools/decode/url — body: {"input":"%encoded%20string"}