URL Encoder & Parser
Runs on your device. Nothing is sent.Everything happens on your own device. Nothing you type or paste is ever sent anywhere.
The result will appear here
Encode or decode URLs and query strings, or parse a full URL into its parts and edit the query string in a live table - entirely in your browser.
A URL can only safely contain a limited set of ASCII characters - anything else, like a space, an ampersand, or a non-Latin letter, has to be percent-encoded as %XX before it can travel inside one. This tool encodes and decodes text using the same rules browsers use, and separately parses a full URL into its protocol, host, port, path, query string, and hash, so you can edit the query parameters in a table and watch the URL rebuild itself live. Everything runs locally in your browser - nothing is ever uploaded.
Frequently asked questions
What is percent-encoding?
Percent-encoding (also called URL encoding) replaces a character with % followed by its two-digit hexadecimal byte value, repeated for each byte of its UTF-8 representation. It's how a URL can carry a space (%20), an ampersand (%26), or an emoji without those characters being confused for part of the URL's own syntax.
What's the difference between encodeURIComponent and encodeURI?
encodeURIComponent escapes everything except a small set of unreserved characters, which makes it the right choice for a single value - a query parameter or a path segment - because it also escapes characters like & and = that would otherwise be read as URL structure. encodeURI is meant for an entire URL: it leaves structural characters like :, /, ?, &, and # alone so the URL keeps working, and only escapes characters a URL genuinely can't contain, like spaces. Running an entire URL through encodeURIComponent breaks it, since it would also escape the slashes and colons.
Should I still use escape() and unescape()?
No. Both were deprecated in the very first edition of the JavaScript standard that also introduced encodeURIComponent, because escape() doesn't encode non-ASCII characters the way HTTP and modern URLs expect - it uses a non-standard %uXXXX form for anything outside Latin-1 that decodeURIComponent can't read back. This tool keeps the option only so you can inspect what a legacy system produced.
Why does a + in a query string turn into a space?
Query strings historically come from HTML form submissions, which use the application/x-www-form-urlencoded format: it encodes a literal space as + instead of %20, and both of those are treated as a space when this tool's parser (and JavaScript's URLSearchParams) decode them. If you actually need a literal plus sign in a value, it must itself be percent-encoded as %2B.
What happens with a repeated parameter like ?tag=a&tag=b?
Nothing is lost - this tool preserves every occurrence, in order, as its own row in the query parameter table, exactly the way most server frameworks collect a repeated key into a list. Editing or removing one row leaves the others untouched.
Why did the parser assume https:// for my URL?
A string like example.com/path has no protocol, so a browser (and this tool) can't tell whether it's a web address, meant for another protocol, or just plain text. Rather than reject it, the parser assumes https:// so you can still inspect and edit it - a hint appears whenever that happens, and you can correct the Protocol field if a different scheme was intended.