Developer Free · no signup

URL Encoder / Decoder

Encode or decode URL components. Use "text|||decode" format to decode.

Paste text to percent-encode characters that would otherwise break a URL — a space becomes %20, an ampersand becomes %26 — or paste an encoded string to decode it back to readable form. URL encoding is essential whenever you put user input, special characters, or non-English text into a query string or path, because unescaped reserved characters change how the URL is parsed. The tool switches between encoding and decoding instantly.

Updated Krawly Editorial TeamIn-house engineers, writers & reviewers

Explore More Free Tools

Discover 150+ free tools for web scraping, SEO analysis, OSINT, and more. 30 free uses every day — no signup required.

150+ Free Tools No Signup Required JSON / CSV / Excel 30 Uses / Day
Quick answer

Paste text to percent-encode characters that would otherwise break a URL — a space becomes %20, an ampersand becomes %26 — or paste an encoded string to decode it back to readable form. URL encoding is essential whenever you put user input, special characters, or non-English text into a query string or path, because unescaped reserved characters change how the URL is parsed. The tool switches between encoding and decoding instantly.

What is URL Encoder / Decoder?

The URL Encoder is a free online tool that percent-encodes and decodes text so it can travel safely inside a URL. It converts reserved and unsafe characters — spaces, ampersands, question marks, and non-ASCII letters — into their %XX escape sequences and back again. Everything runs in your browser, so the values you convert are never uploaded.

How to use URL Encoder / Decoder

  1. 1

    Choose encode or decode

    Decide whether you're turning readable text into a URL-safe form or turning a percent-encoded string back into plain text, and set the tool to that direction.

  2. 2

    Paste your text

    Drop the value into the input field. When encoding, enter just the piece you want to escape — usually a single query-parameter value — rather than a whole URL, so you don't accidentally escape the : and / that the URL structure needs.

  3. 3

    Read the converted result

    The output appears immediately. Encoded text shows %XX sequences for every unsafe character, where a space becomes %20 and a plus or ampersand gets its own escape code.

  4. 4

    Assemble your URL

    Copy the encoded value into the correct part of your URL. Keep in mind that path segments and query values have slightly different rules, so encode each component on its own rather than the full URL at once.

Try it when you need to…

  • A search link breaks whenever the query contains a space, ampersand, or special symbol
  • You copied an encoded URL from server logs and need to read the real parameter values
  • You're building an API call whose parameter value contains characters that clash with URL syntax

Use cases

  • Safely place user search terms with spaces and symbols into a query-string parameter
  • Decode a messy URL from a log or redirect to read the actual parameter values
  • Encode non-ASCII characters like accented letters or emoji so they survive in a URL
  • Build API request URLs where parameter values contain &, =, or ? that must be escaped
  • Fix a broken link where an unencoded space or special character split the URL

Key features

Two-way conversion — percent-encode text and decode %XX sequences back to plain text
Correctly escapes reserved characters and encodes non-ASCII as UTF-8 byte sequences
Instant output that updates as you type or paste
One-click copy of the encoded or decoded result
Runs fully client-side so nothing you enter is sent to a server

Tips & best practices

Encode each URL component separately, not the whole URL. Encoding a complete URL escapes the :// and / structure and breaks it — escape only the individual parameter values.

A space can legally be encoded as either %20 or a + sign, but only inside the query string. In the path portion of a URL, a space must be %20, since + there means a literal plus.

Reserved characters like & = ? # / have structural meaning in a URL. If a parameter value contains one of them, it must be encoded or the URL will be parsed incorrectly.

Non-ASCII characters are first converted to their UTF-8 bytes and then each byte is percent-encoded, so a single accented letter can turn into two or three %XX sequences.

Frequently asked questions

URL encoding, also called percent-encoding, replaces characters that aren't allowed or have special meaning in a URL with a % followed by their hexadecimal byte value. It's needed because characters like spaces, ampersands, and question marks would otherwise be misinterpreted as delimiters, breaking how the URL is parsed and where one parameter ends and the next begins.

Encode only the individual components — typically each query-parameter value or path segment — not the entire URL. Encoding the whole thing would escape the essential :// and / characters that define the URL's structure, turning a valid address into a broken string.

Both can represent a space, but the context matters. In the query string, application/x-www-form-urlencoded rules allow a + for a space, while %20 works everywhere. In the path portion of a URL, only %20 is a space — a + there is treated as a literal plus sign, so %20 is the safest universal choice.

Reserved characters with structural meaning (: / ? # [ ] @ ! $ & ' ( ) * + , ; =), the space, and any non-ASCII character need encoding when they appear inside a value rather than as structure. Unreserved characters — letters, digits, and - _ . ~ — never need to be encoded.

Characters outside the ASCII range are first encoded to their UTF-8 byte sequence, and then each byte is percent-encoded individually. That's why a single accented letter or emoji can expand into multiple %XX groups — it reflects the multiple bytes UTF-8 uses to represent that character.

No. URL encoding uses %XX sequences to make text safe inside a URL, while HTML encoding uses entities like & and < to safely display special characters in a web page. They solve different problems, so a value going into a URL needs URL encoding, not HTML entities.

No. The encoding and decoding are performed in your browser with built-in functions, so the text you enter never leaves your device. You can safely process URLs or parameter values that contain sensitive information.