URL encoder

What Is URL Encoding?

URL encoding — also called percent-encoding — is the mechanism that makes arbitrary text safe to include in a web address. URLs were designed around a limited set of characters, so anything outside that set (spaces, punctuation, non-English letters, emoji) must be transformed before it can travel inside a URL. The transformation is simple: each unsafe byte is replaced with a % sign followed by two hexadecimal digits representing the byte's value. A space becomes %20, an exclamation mark becomes %21, and the Urdu letter ب becomes %D8%A8 (its two UTF-8 bytes, each percent-encoded).

Without URL encoding, the web's addressing system would constantly misinterpret user input. A search query for "fish & chips" contains an ampersand — but in a URL, & separates query parameters, so the raw query would be parsed as two parameters ("fish " and " chips") instead of one phrase. A ? inside user input would be read as the start of a new query string; a # would truncate everything after it as a fragment. Encoding neutralizes these characters by converting them into inert %XX sequences that servers decode back to the original text after parsing the URL's structure.

The character set splits into three groups. Unreserved characters — A–Z, a–z, 0–9, hyphen, underscore, period, tilde — are never encoded. Reserved characters (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) have structural meaning in URLs and are encoded only when they appear as data rather than structure. Everything else — spaces, quotes, angle brackets, non-ASCII text — is always encoded. This distinction is why good encoders offer "encode component" versus "encode full URL" modes: encoding a complete URL must preserve the structural characters, while encoding a single value must escape them.

The WebTaskTools URL encoder converts any text you paste into properly percent-encoded output instantly, handling UTF-8 correctly for non-English text. Whether you're building a query string by hand, debugging an API call, or preparing tracking links for a campaign, the encoder removes the guesswork from a process where one unescaped character can silently corrupt your data. Your input is processed instantly and never stored. To reverse the process, use our URL decoder; for the related Base64 transformation, see our Base64 encoder.

How to Use the URL Encoder

1. Paste or type your text. Enter the string that needs to go inside a URL — a search term, a form value, a filename, or a full address.
2. Choose encode mode. Use component mode for a single value (a query parameter, a form field); use full URL mode when encoding an entire address, so structural characters like : / ? & are preserved.
3. Click Encode. The tool instantly returns the percent-encoded string with correct UTF-8 handling.
4. Copy the output. Use the copy button to grab the encoded text without missing characters or introducing typos.
5. Insert it into your URL. Place the encoded value into the query string, path segment, or form action where it belongs.
6. Decode to verify. Run the result through our URL decoder to confirm it round-trips to your original text.

Encoding in Action: Before and After

Key Features

• Component and full-URL modes — encode a single value aggressively or a whole address while preserving its structure.
• Correct UTF-8 handling — non-English scripts (Urdu, Arabic, Chinese, accented Latin) encode to proper multi-byte %XX sequences.
• Instant results — output appears the moment you encode; no waiting, no submit round-trip.
• One-click copy — long encoded strings copied without selection errors.
• Round-trip verification — decode with our URL decoder to confirm fidelity.
• Not stored — input is processed instantly and never stored, logged, or retained.
• Free and unlimited — encode as much text as you need, with no accounts, no quotas, and no cost.

encodeURI vs. encodeURIComponent: The Critical Distinction

JavaScript exposes two encoding functions, and choosing wrong is a top-ten web bug. encodeURI() encodes a complete URI, leaving structural characters (; , / ? : @ & = + $ - _ . ! ~ * ' ( ) #) untouched — it's for when you already have a valid URL that just needs its unsafe characters fixed. encodeURIComponent() encodes a component — a single query value or path segment — escaping everything except A–Z a–z 0–9 - _ . ! ~ * ' ( ). It's for building URLs from untrusted pieces.

The classic bug: building https://shop.com/search?q= + userInput with encodeURI() on the whole thing. If the user typed "shoes & socks," the & survives encoding (encodeURI preserves it as structural), and the server sees two parameters: q=shoes and socks=. The fix is encodeURIComponent(userInput), which escapes the & to %26 so the value arrives intact. Rule of thumb: never encode a full URL with the component encoder (it will escape the : and / and destroy the address), and never build query strings with the full-URL encoder (it leaves user-supplied &, =, and # live). This tool's two modes map exactly to these two functions.

Use Cases

Web developers

The problem: User input flows into URLs everywhere — search boxes, filter links, redirect targets, share buttons. Unencoded input breaks parsing, and inconsistent encoding between frontend and backend causes bugs that only appear with certain characters.

How this tool helps: Encode test values quickly while debugging, generate correctly-encoded fixtures for automated tests, and verify what the browser actually sends by comparing against the tool's output.

SEO specialists

The problem: Non-English URLs, campaign UTM parameters with spaces and special characters, and migrated URLs with legacy encodings all need to be valid, consistent, and crawlable.

How this tool helps: Produce canonical encoded forms of URLs before publishing, verify that tracking parameters survive encoding intact, and diagnose crawl errors caused by malformed percent-encoding.

Marketers building tracking links

The problem: A UTM-tagged URL pasted into an email or ad platform breaks because the campaign name contained spaces or an ampersand, silently corrupting attribution data.

How this tool helps: Encode each parameter value before assembling the tracking URL, so analytics receive exactly the campaign names you intended — no truncated or split parameters.

API developers and testers

The problem: Testing an endpoint with a query like ?q=C++ & Java fails mysteriously — the plus signs became spaces and the ampersand split the parameter.

How this tool helps: Encode tricky test inputs in component mode before firing requests in Postman or curl, and decode server logs to confirm what the backend actually received.

Content creators sharing links

The problem: A link to a page with a non-English title looks like terrifying percent-gibberish when pasted, or worse, breaks when shared through certain apps.

How this tool helps: Verify the encoded form is valid before sharing, and understand that the %XX sequences are normal — browsers display the decoded title while transmitting the encoded form.

Students learning web fundamentals

The problem: Percent-encoding is taught as a table to memorize, which makes it feel arbitrary.

How this tool helps: Type familiar text — your name, a phrase in your language — and watch it transform. Encoding "café" and seeing %C3%A9 makes the UTF-8-byte concept concrete in a way tables never do.

Reserved Characters: What Each One Does in a URL

Reserved characters are the punctuation of the URL language — each has a structural job, which is exactly why it must be encoded when it appears as data. This table covers the full reserved set from RFC 3986:

Memorizing the table isn't necessary — the practical skill is recognizing symptoms. A search that loses everything after a "#" means a fragment cut the value. Parameters that multiply unexpectedly mean an unencoded &. A plus sign arriving as a space means form-decoding ate it. Each symptom maps to one row of this table, and the fix is always the same: encode the value as a component before assembling the URL.

URL Encoding and Security

Encoding is not a security boundary, but mishandled encoding creates security holes. The classic is the open redirect: a login page redirects to ?next=/dashboard, and an attacker supplies ?next=https%3A%2F%2Fevil.com — properly encoded, so it passes naive validation, then decoded by the app into an off-site redirect that carries the user's session context to a phishing page. The defense is allowlist validation of the decoded value, not blocking encoded input.

Double-encoding attacks exploit decoders that run twice: an attacker sends %252E%252E (encoded %2E%2E), the first decode yields %2E%2E which a naive filter sees as harmless, and the second decode yields ".." — a path traversal the filter was supposed to block. The defense is to decode exactly once, validate, and never decode again. Over-encoding can also be weaponized in reverse: some WAFs inspect only the raw request, so %3Cscript%3E sails past a filter looking for literal <script> and executes after the app decodes it. Modern WAFs normalize before inspecting, but the arms race continues.

The takeaway for builders: decode once at the trust boundary, validate the decoded value against an allowlist, and re-encode when emitting it into a new context (HTML-encode for pages, URL-encode for links, parameterize for SQL). Encoding correctly is necessary but not sufficient — it's one layer in a validation strategy, not the strategy itself.

International Domains: Punycode vs. Percent-Encoding

Non-English text appears in two different parts of a web address, and each uses a different encoding — a frequent source of confusion. In the path and query, non-ASCII characters use percent-encoding as described on this page: each UTF-8 byte becomes %XX. But in the domain name, percent-encoding is not allowed at all. Internationalized domain names (like مثال.com) instead use Punycode, an encoding that converts Unicode domains into ASCII strings prefixed with xn-- (مثال.com becomes xn--mgbh0fb.com).

Browsers handle the translation invisibly: you type or see مثال.com while the network actually requests xn--mgbh0fb.com. This split exists because the DNS system predates Unicode and only understands ASCII. The security implication is homograph attacks — Cyrillic "а" looks identical to Latin "a," so аpple.com (Cyrillic) and apple.com (Latin) are different domains with different Punycode forms. Modern browsers mitigate this by displaying the Punycode form when a domain mixes scripts suspiciously. For builders, the rule is simple: percent-encode everything after the domain, Punycode-encode (or let the browser handle) the domain itself, and never mix the two.

Frequently Asked Questions

What does %20 mean in a URL?

%20 is the percent-encoded form of a space (hex 20 = decimal 32 = the ASCII space character). It's the most common %XX sequence you'll see. In query strings you may also see "+" used for spaces — that's the HTML form-encoding convention, distinct from percent-encoding, though most servers accept both.

Should I encode the entire URL or just parts of it?

Just the parts — the individual values. Encode each query parameter value and each dynamic path segment with the component encoder, then assemble them into the URL. Encoding an entire URL with a component encoder destroys it (the :// becomes %3A%2F%2F); encoding values with a full-URL encoder leaves dangerous characters like & and # live inside your data.

Why do non-English characters become so long when encoded?

Because percent-encoding operates on bytes, not characters. UTF-8 represents non-Latin characters with 2–4 bytes each, and every byte becomes 3 characters (%XX). An Urdu or Chinese character therefore expands to 6–12 characters in the URL. The browser displays the decoded form to users, so this only affects the raw address.

What's the difference between URL encoding and Base64?

URL encoding escapes only the characters that are unsafe in URLs, leaving the rest readable — ideal for short text values inside addresses. Base64 transforms everything into a 64-character alphabet — ideal for binary data that must travel through text channels. Use URL encoding for URL parts; use our Base64 encoder for binary payloads.

Can I encode a URL twice?

You can, but you almost certainly shouldn't — double encoding is a bug, not a feature. Encoding %20 again produces %2520 (the % itself gets encoded to %25), and the server will decode it once to %20 instead of to a space. If you see %25 in unexpected places, double encoding is the prime suspect.

Do I need to encode spaces in a URL path?

Yes. Browsers will often fix it for you when you paste an address into the address bar, but programmatically constructed URLs with raw spaces are invalid per the spec and break in HTTP clients, APIs, and many apps. Always encode spaces as %20 in paths (in query strings, + is also acceptable).

Why does my API receive different data than I sent?

Almost always an encoding mismatch: the client encoded with one convention and the server decoded with another. Common culprits include + decoded as space (or not), %2F in path segments being rejected by servers that block encoded slashes, and UTF-8 text decoded as Latin-1 producing mojibake. Log the raw received bytes on the server to see exactly what arrived.

Are encoded URLs bad for SEO?

No — search engines handle percent-encoded URLs routinely, including non-English addresses. What hurts SEO is inconsistency: the same page reachable via encoded, unencoded, and double-encoded variants looks like duplicate content. Pick one canonical form and redirect the others to it.

What characters never need encoding?

The unreserved set: A–Z, a–z, 0–9, hyphen (-), underscore (_), period (.), and tilde (~). Everything else is either reserved (encode when used as data) or unsafe (always encode). When in doubt, encoding a safe character is harmless — %41 decodes to "A" just fine — so err on the side of encoding.

Is my input stored when I encode it?

No. Text is processed instantly to produce the encoded output and never stored, logged, or retained. URLs containing session tokens or personal data are safe to encode here, though as a habit you should prefer your own tooling for live production credentials.