Percent-encode text for safe use inside a URL component. Use URL encode without creating an account. The workbench keeps the source and result together so you can check the output before downloading it.
URL encode covers building query parameters, encoding redirect values, and preparing API request data. Its controls stay on one page, with status and validation messages beside the work area.
Your input and generated result are processed in your browser and are not sent to a PWRKIT processing server. If the input contains sensitive information, follow your organization’s rules for online utilities.
Before using the result, confirm that text destined for a URL parameter or path is complete and that percent-encoded URL-safe text matches the destination format. Keep the original until you have checked the output in the application or context where it will be used.
The related developer tools cover the next common tasks without changing your original input.
- 01
Provide text destined for a URL parameter or path. The tool checks the input before processing it.
- 02
Adjust the available url encode settings for the result you need.
- 03
Run URL encode. If the input is incomplete, the workbench explains what to correct.
- 04
Check percent-encoded URL-safe text, then copy or download the result. Your original input stays unchanged.
- building query parameters
- encoding redirect values
- preparing API request data
Is URL encode free to use?
Yes. URL encode is available without an account or subscription.
Does URL encode upload my input?
URL encode processes your input in your browser. Your entered content and generated result are not sent to a PWRKIT processing server.
Does URL encode change the original?
No. URL encode leaves the source untouched. Copy or download the generated result as a separate output.
What should I check after using URL encode?
Confirm that percent-encoded URL-safe text matches the intended format and context. Keep the original until the result has been verified.
URL encode applies JavaScript's encodeURIComponent operation to the entire input. It preserves letters, digits, hyphen, underscore, period, exclamation mark, tilde, asterisk, apostrophe, and parentheses. Other characters are converted to percent-encoded UTF-8 bytes. A space becomes %20, an ampersand becomes %26, and a slash becomes %2F. The result is intended to occupy one component value, such as a query parameter value or a path segment, without its reserved characters being mistaken for surrounding URL syntax.
The tool does not ask which component you are building, so the user must preserve the URL structure. Enter the value itself rather than an entire assembled URL when scheme separators, path slashes, query delimiters, and fragment markers must remain functional. Encoding https://example.com/search?q=red shoes as one input hides its colon, slashes, question mark, and equals sign. That output could be valid as a nested parameter value, but it is not the normal encoded form of the original top-level URL.
To build a search query for red shoes & boots, encode only that phrase. The result is red%20shoes%20%26%20boots. A calling application can then append it after a parameter name and equals sign, producing ?q=red%20shoes%20%26%20boots. The encoded ampersand remains data inside q rather than starting another parameter. If the name itself is dynamic, encode the name separately. Join encoded names and values with the literal structural equals and ampersand characters after each component is prepared.
For a path example, the segment invoices/2026 contains a slash that may either separate two path segments or belong to one value. Encoding the whole string returns invoices%2F2026, which represents one component containing a slash. Encoding invoices and 2026 separately and joining them with a literal slash represents two components. Both forms can be intentional and can route differently. Decide the data model first. Percent encoding preserves the distinction only when the application retains component boundaries during construction and parsing.
Non-ASCII characters are converted through UTF-8 and written as one or more percent triplets. The check mark ✓ becomes %E2%9C%93, while many emoji require four bytes. Accented letters can produce different byte sequences if visually identical text uses different Unicode normalization forms. The tool does not normalize the input before encoding. Systems that sign, hash, compare, or cache URLs may treat those byte sequences as different, so normalization policy must be defined by the application rather than guessed during manual encoding.
encodeURIComponent can throw on malformed JavaScript strings containing an unpaired UTF-16 surrogate. Ordinary typed text rarely creates that condition, but damaged data or programmatically constructed strings can. The workbench reports the error instead of manufacturing replacement bytes. Recover or repair the source under a documented Unicode policy. Do not replace an unknown invalid unit with a convenient character when the value identifies an account, file, callback, or signed request, because the altered bytes represent different data.
HTML form serialization commonly uses application/x-www-form-urlencoded rules, where spaces are written as plus signs and literal plus signs are percent-encoded. This tool uses encodeURIComponent, so spaces become %20. Both representations are widely encountered, but a server or signature routine may expect one exact form. The tool does not build a complete form body, repeat field names, order parameters, or apply a framework's serializer. Use the same encoder as the receiving protocol when byte-for-byte agreement matters.
A plus sign in the input becomes %2B, which protects it from form decoders that would otherwise interpret plus as space. An ordinary space becomes %20 and most form decoders accept that representation in a query value, though protocol-specific software can be stricter. Do not manually replace every %20 with plus unless the target explicitly uses form encoding. A URL, a form body, and a canonical string used for signing can apply related but nonidentical rules. Capture a known-good request from the target client when reproducing a mismatch.
Encoding happens in the browser and does not navigate to the result or contact the encoded hostname. The input and output are held in the workbench's current state, and Reset clears both displayed values. Copy uses the system clipboard. This lets you prepare an ordinary component without submitting it to a PWRKIT processing endpoint. It does not test whether a completed URL resolves, whether the destination accepts the parameter, or whether a signed value remains valid after modification.
URLs often contain private information despite being treated casually. Query values can include email addresses, internal document names, account identifiers, tokens, and redirect destinations. Percent encoding is reversible representation, not encryption or redaction. Anyone who receives the URL can decode it, and URLs may be stored in browser history, proxy logs, analytics systems, referrer headers, screenshots, or clipboard history. Do not put secrets in a URL merely because their characters are encoded. Follow the destination's guidance for sensitive values.
The output does not validate a scheme, hostname, redirect policy, path traversal rule, parameter allowlist, or maximum URL length. It cannot tell whether the receiving application will decode once, decode repeatedly, or normalize reserved characters before routing. Encoding an unsafe destination does not make an open redirect acceptable, and encoding an injection payload does not authorize it as data. The application must parse the final URL and validate each decoded value according to its intended type and trust boundary.
The converter also does not produce every specialized URL representation. It does not convert Unicode domain names to Punycode, preserve a full URL's required delimiters, generate URLSearchParams output, sort query pairs, remove tracking parameters, or normalize percent triplet case. It leaves the characters permitted by encodeURIComponent unescaped, including apostrophe and parentheses, although a particular protocol or style policy might encode more. Apply the target specification rather than assuming one encoding function fits every URL-related format.
If a link loses its structure, check whether the complete URL was encoded instead of its values. Restore the original, parse it into components, and encode only the dynamic pieces. If a server receives literal %20 instead of a space, an intermediate layer may not be decoding, or the percent sign may have been encoded again as %25. A value containing %2520 is commonly one layer away from %20 and two layers away from a space. Trace each serializer and decoder rather than applying repeated conversion without context.
If a signature or callback comparison fails, compare the exact bytes, parameter order, space convention, percent-triplet capitalization, and Unicode normalization expected by the protocol. This page supplies encodeURIComponent output only. If the browser rejects the input, look for damaged Unicode copied from another system. For a known-good check, A B&C should become A%20B%26C. Test the completed URL in a safe nonproduction environment, then verify that the application receives the intended decoded field rather than merely checking that the address bar looks readable.
A correct fragment can still be placed into the wrong part of a URL. After assembly, parse the final address with the same platform API used by the application and inspect the resulting pathname, parameter names, parameter values, and fragment. Verify repeated parameters separately. If a value contains a nested URL, confirm that its question mark and ampersands remain inside that value after the outer URL is parsed. A visual scan of percent triplets cannot replace structural inspection.
For API calls, compare a known-good request from official client code with the manually assembled request. Look at method, headers, body, and signing rules as well as the URL. Some services canonicalize parameters before signature calculation, while others require the exact transmitted representation. The tool does not know that contract. Store regression fixtures containing raw values, encoded components, assembled URLs, and expected parsed values so a later change in construction code can be reviewed without relying on memory.
Use allowlists for destinations and accepted value shapes after decoding. Percent encoding can transport a colon, slash, newline, or markup character, but transportability does not make that character appropriate for the field. Validate length, type, host, path, or identifier rules at the receiving boundary. Encoding and validation solve separate problems: encoding protects structure during transport, while validation decides whether the represented value is allowed to participate in the requested operation. Log rejected values carefully, since decoded credentials or personal data should not be copied into routine diagnostic messages. Prefer a bounded error code and the field name when the raw value is unnecessary.