URL encoding, also called percent-encoding, replaces characters that would break a web address with a percent sign and two hex digits, and the Best Answer Hub URL Encoder does it in both directions and in your browser, so nothing you paste is sent to a server. This guide explains what percent-encoding is, which characters need it, why a space becomes %20 in a URL but a plus sign in a form, the encodeURI versus encodeURIComponent choice that trips up most developers, and the double-encoding bug behind a stray %2520.
What is the Best Answer Hub URL Encoder/Decoder?
The Best Answer Hub URL Encoder/Decoder is a single-page tool that percent-encodes and decodes text and URLs, with two modes: Component mode for a single value such as one query parameter, and Full URL mode for a whole address. It encodes and decodes in either direction and runs entirely in your browser with the native JavaScript functions, so nothing is transmitted, nothing is stored, and it keeps working offline. It needs no account and shows no ads. The tool sits in the Best Answer Hub Developer Toolbox and the wider Tools hub, is built and maintained by Shahbaz Ali Malik, and stays free because Best Answer Hub is funded by optional paid assessments rather than advertising.
What is URL encoding and why is it needed?
URL encoding represents a character as a percent sign followed by two hexadecimal digits of its byte value, so that characters with a special meaning, or none allowed in a URL, can travel safely. RFC 3986, the standard that defines URLs, puts it exactly: "A percent-encoded octet is encoded as a character triplet, consisting of the percent character followed by the two hexadecimal digits representing that octet's numeric value." Modern URLs encode text as its UTF-8 bytes, so an accented letter like e-acute becomes its two bytes, %C3%A9 (WHATWG URL Standard). Without encoding, a space, an ampersand, or a non-English character would break the link or be misread by the server.
Which characters need to be encoded?
The characters that never need encoding are the unreserved set, and everything with a structural role must be encoded when it appears in data rather than as a delimiter. RFC 3986 defines the unreserved characters as the letters, digits, hyphen, period, underscore, and tilde (RFC 3986). The reserved characters, the delimiters like : / ? # [ ] @ and ! $ & ' ( ) * + , ; =, carry meaning in a URL, so if one of them is part of a value it must be percent-encoded (RFC 3986). The percent sign itself is always encoded, to %25, because it starts an encoding triplet. The table sets out the groups.
| Group | Characters | Encoded? |
|---|---|---|
| Unreserved | A-Z a-z 0-9 - . _ ~ | Never |
| Reserved (delimiters) | : / ? # [ ] @ ! $ & ' ( ) * + , ; = | When used inside a value |
| Percent | % | Always, to %25 |
Why does a space become %20 or a plus sign?
It depends on where the space appears. In a URL path or a normal query, a space is encoded as %20. In an HTML form body sent as application/x-www-form-urlencoded, a space is encoded as a plus sign instead. MDN states it plainly: a space is translated to "a plus, like in the percent-encoding version used in an application/x-www-form-urlencoded message, or in %20 like on URLs" (MDN). The practical consequence is that JavaScript's encodeURIComponent produces %20, so for a form-urlencoded body you sometimes replace %20 with a plus, and a decoder has to know the context, because in form data a plus means a space but in a path a plus is a literal plus.
encodeURI vs encodeURIComponent: which do you use?
Use encodeURIComponent for a single piece you are dropping into a URL, and encodeURI for a whole URL you do not want to break. MDN is direct: encodeURI "is used to encode a URL as a whole," while for assembling values "you probably want to use encodeURIComponent() on each dynamic segment instead" (MDN). The difference is what each one leaves alone: encodeURI keeps the URL delimiters : / ? # & = intact, while encodeURIComponent encodes them too, which is exactly what you want for a query value. The Best Answer Hub URL Encoder offers both as Full URL and Component modes so the right one is a click away.
Encode the whole URL with encodeURI and an ampersand inside a value survives and is read by the server as a new field. Encode the value with encodeURIComponent (Component mode) and it becomes %26, so the value stays intact.
If a user writes Jack & Jill, without encodeURIComponent the ampersand could be interpreted on the server as the start of a new field and jeopardize the integrity of the data.MDN Web Docs, encodeURIComponent
Why is my URL showing %2520?
A stray %2520 means the string was encoded twice. Because the percent sign is itself a reserved trigger, encoding an already-encoded string turns every percent into %25, so a space that was already %20 becomes %2520, and an ampersand that was %26 becomes %2526 (MDN). Decoding it once is not enough; you get back a still-encoded string and have to decode again. The fix is to encode a value exactly once, and when decoding, if you still see %20 or %26 in the result, decode a second time. The Best Answer Hub URL Encoder shows the output immediately, so a double-encoded input is easy to spot and correct.
Encode once, decode once. If you paste text that is already encoded into an encoder, you double it. If a decode leaves visible percent sequences behind, the input was double-encoded, so decode again. Watching the live output catches both cases before they reach production.
Is it safe to paste a URL with a token into an online encoder?
It is safe only if the encoding happens on your own device, and many online encoders do it on their servers. Developers routinely encode URLs that carry sensitive material: session IDs, bearer tokens, signed query parameters, and internal hostnames. Two of the most popular encoders process on their servers by default and offer a browser-local "Live mode" only as an opt-in (urlencoder.org), and FreeFormatter's own privacy statement confirms its tools use "server side processing" (FreeFormatter). Even with a no-retention promise, the data is still sent to a third party. There is a real security dimension too: attackers double-encode characters to slip past naive input filters, which is why understanding encoding matters when reviewing code (OWASP). The Best Answer Hub URL Encoder runs client-side by default, so a token never leaves your browser.
How is it different from other online encoders?
The difference is that the Best Answer Hub URL Encoder is client-side by default, always, where the popular encoders process on their servers unless you switch on a limited opt-in mode. It also makes the two choices that matter explicit, Component versus Full URL, and it both encodes and decodes. The table sets the usual experience next to this one.
| What you get | Best Answer Hub | Typical online encoder |
|---|---|---|
| Where encoding happens | In your browser, always | Often server-side by default |
| Data sent to a third party | None | Yes in default modes |
| Component vs whole-URL | Both, clearly labeled | Often one generic mode |
| Encodes and decodes | Both | Usually both |
| No signup, no ads | Yes | Varies |
| Works offline | Yes | Not in default server mode |
The Best Answer Hub Developer Toolbox has the neighbors you reach for next: a Base64 Encoder for the other everyday encoding, and a JSON Formatter for the payloads those URLs carry. Each runs in the browser and sends nothing.
Open the URL Encoder
Free, no signup, and encoded entirely in your browser. Switch between Component and Full URL mode, encode or decode, and copy the result without sending a thing to a server.
Encode or decode a URLCommon questions about URL encoding
Keep going
- →Free Developer Tools That Run in Your Browser The Developer Toolbox guide, from a JSON formatter to a hash generator, all keeping your data local.
- →Base64 Is Encoding, Not Encryption The other everyday encoding, and why it is not a way to hide anything.
- →Format and Validate JSON, Nothing Uploaded For the payloads your encoded URLs carry.
- →70+ Free Online Tools, Nothing Uploaded The overview of every Best Answer Hub hub.
Sources
- IETF, RFC 3986, URI Generic Syntax, Section 2.1, 2005 (the percent-encoded triplet definition).
- IETF, RFC 3986, Section 2.3, 2005 (unreserved characters: letters, digits, hyphen, period, underscore, tilde).
- IETF, RFC 3986, Section 2.2, 2005 (reserved characters and their delimiter roles).
- MDN Web Docs, Percent-encoding (space becomes a plus in form-urlencoded, %20 in URLs).
- MDN Web Docs, encodeURI() and encodeURIComponent() (which to use; the Jack and Jill ampersand example; double-encoding).
- WHATWG, URL Standard, percent-encoded bytes (UTF-8 percent-encoding; the plus for a space in form-urlencoded).
- OWASP, Double Encoding (double-encoded characters used to bypass input filters).
Jump into the tools: URL Encoder/Decoder, Developer Toolbox, Base64 Encoder, and all Tools.