InstantToolsPro
✔ 100% Free – No Signup Required
InstantToolsPro
Encode URLs and query strings instantly with smart auto-detection. Build query parameters, decode encoded URLs, and handle special characters — all live.
Type a URL, query string, or plain text. The tool auto-detects whether to encode or decode.
Use "Component" mode for query values, "Full URL" to preserve URL structure characters.
Use the Query Builder to add key-value pairs and auto-generate a fully encoded URL.
One-click copy the result or download as a .txt file. Swap output to input to chain operations.
URL encoding (also called percent-encoding) converts characters that are not allowed in a URL into a format that can be transmitted over the internet. Each unsafe character is replaced by a % followed by two hexadecimal digits. For example, a space becomes %20, and a slash becomes %2F.
encodeURIComponent encodes everything except letters, digits, and - _ . ! ~ * ' ( ). It's used for encoding individual query parameter keys and values. encodeURI preserves URL structure characters like : / ? # @ ! $ & = + , and is used when you need to encode a complete URL without breaking its structure.
The Query String Builder lets you add key-value pairs through a visual interface and generates a fully encoded URL automatically. For example, adding name=John Doe and city=New Delhi generates ?name=John%20Doe&city=New%20Delhi. This is particularly useful for building API endpoints, search URLs, and form submissions.
URLs are restricted to a specific set of safe characters because certain characters already carry structural meaning within a URL. A ? marks the start of a query string, an & separates parameters, a # marks a fragment identifier, and a / separates path segments. If those characters appeared unencoded inside a value — say, inside a search term or a username — the URL parser would misinterpret where one part of the URL ends and another begins. Percent-encoding is what keeps arbitrary text safe to embed inside a URL without corrupting its structure.
Component mode behaves like encodeURIComponent — it aggressively encodes everything except the safest characters, which makes it the right choice when you're encoding a single value that will be inserted into a query string, such as a search term or a form field value. Full URL mode behaves like encodeURI — it preserves the structural characters of a complete URL, so encoding an entire link doesn't break its slashes, question marks, or ampersands. Picking the wrong mode is the most common reason an encoded URL ends up looking broken or "double encoded."
Standard percent-encoding (RFC 3986) represents a space as %20. However, an older convention used specifically for HTML form submissions (application/x-www-form-urlencoded) represents a space as + instead. Both are valid in their respective contexts, but mixing them up causes bugs — a + decoded incorrectly as itself instead of as a space shows up as a literal plus sign in your data. If you're working with form-submitted data, expect + for spaces; for URLs and query strings you're building manually, %20 is the standard.
Double encoding happens when an already-encoded string gets encoded a second time, turning something like %20 into %2520 (since the % character itself gets re-encoded into %25). This commonly happens when a full URL is encoded using Component mode instead of Full URL mode, or when a value is passed through an encoding function twice in application code — once manually, and once automatically by a framework or library. The result is a URL that looks broken and, when decoded once, still contains percent-encoded characters instead of the original readable text.
Certain characters come up constantly when encoding URLs and query values. A space becomes %20, a forward slash becomes %2F, a question mark becomes %3F, an ampersand becomes %26, an equals sign becomes %3D, a hash symbol becomes %23, an at symbol becomes %40, a colon becomes %3A, a plus sign becomes %2B, and the percent sign itself becomes %25 — since % is the escape character used by encoding, it must be encoded when it appears literally in your data.
Common questions about how URL encoding works and how to use this tool correctly.
encodeURIComponent encodes almost every character except letters, digits, and a few safe symbols — used for individual values. encodeURI preserves structural URL characters like /, ?, and & — used for encoding a complete URL without breaking its structure.
%20 is the standard percent-encoding for a space. + is used specifically in HTML form submission encoding. Both represent a space, but in different contexts — mixing them up in the wrong context can cause decoding errors downstream.
URLs can only safely contain a limited character set. Characters like spaces, ampersands, and question marks either aren't allowed or have structural meaning, so encoding converts unsafe or ambiguous characters into a safe percent-encoded format that can be transmitted and parsed correctly by servers and browsers.
Check whether your input is already encoded before converting it again — if it already contains sequences like %20 or %3D, encoding it a second time will corrupt those sequences. Also make sure you're not encoding the same value both manually and automatically through a framework's built-in URL handling.
Yes — the Query String Builder lets you add multiple key-value pairs through a visual interface and automatically generates a correctly encoded, properly joined query string, including handling the base URL and the leading question mark.
No — encoding and decoding happen instantly in your browser, so your text and URLs are never sent to or stored on any server.
URL encoding comes up constantly in everyday development work. Building search functionality often means taking a user's search term — which might include spaces, special characters, or even other languages — and safely inserting it into a query string without breaking the URL. API integrations frequently require encoding parameter values before appending them to an endpoint, especially when those values come from user input rather than fixed, predictable strings. Sharing links that include tracking parameters, redirect URLs, or embedded data (like a return URL after a login flow) also requires careful encoding, since a single unencoded ampersand or equals sign inside a parameter value can silently break the entire link's structure.