Have to deal with URL encoded format? Then this tool is made for you! Use the super simple online form below to decode or encode your data. Welcome!

Privacy policy of urldecoder.org

This document was last updated on Aug 8, 2018 We are committed to protect and respect your privacy. This privacy policy describes and governs our information collection, use, and sharing practices. Before you submit/upload any information or file to our websites, please carefully review this policy.

  • We DO NOT keep or inspect any information (e.g.: text, setting) or file submitted/uploaded to our websites.
  • We DO NOT ask for, or require any personal information (e.g.: name, username, password, email address, credit card) at our websites.
Data controller

For the purpose of data protection laws applicable from time to time to you in the location that you provide your information, we are the "data controller" for the information you provide through our websites. There may be other controllers as well (e.g.: advertisers), and we encourage you to consult their privacy policies to learn more about their privacy practices.

Our primary data controller's contact:

Zoltán Hajdú
Email: contact@urldecoder.org
Mobile: +36-30-608-85-50

Information we collect

Please note that this privacy policy applies only to information collected through our websites and not to information you may provide to any third-party sites to which we may link to.
  • We make use of web server log files. The information inside these log files are IP address, date/time stamp, referring/exit page, and type of browser. We use this information solely to administer our websites.
  • We use third-party ad server service Google Adsense and web analytics service Google Analytics. We allow them to serve tailored ads to you and to access their own cookies or other tracking technologies on your device you use to access our websites. The information (including your IP address) collected via these technologies are collected directly by these service providers, who use the information to evaluate your use of our websites.

We and our third-party service providers (detailed above) may also collect data about your use of our websites through the use of cookies. Your usage of our websites without changing your browser cookies settings will indicate your consent understanding of our use of cookies in accordance with this section of this policy. You can change your cookie settings at any time. Please consult the "Help" section of your browser for more information. Please note that by blocking any or all cookies, you may not have access to certain features or offerings of our websites.

We and our third-party service providers use the following cookies:
  • Functionality cookies. These are used to recognise you when you return to our websites. This enables us to personalise our content for you, and remember your preferences.
  • Targeting cookies. These cookies record your visit to our websites, the pages you have visited and the links you have followed. We will use this information to make our website and the advertising displayed on it more relevant to your interests.
  • Analytical/performance cookies. They allow us to recognise and count the number of visitors and to see how visitors move around our websites when they are using it. This helps us to improve the way our websites works.
Data retention
  • Our web server log files are deleted after 90 days.
  • Our Google Analytics tracking code is configured to store data that is associated with cookies, user identifiers, or advertising identifiers for up to 14 months.
If you require more information or have any questions about our privacy policy, please feel free to contact us.


Meet URL Decode and Encode, a simple online tool that does exactly what it says; decodes URL encoding and encodes into it quickly and easily. URL encode your data in a hassle-free way, or decode it into human-readable format.

URL encoding, also known as percent-encoding, is a mechanism for encoding information in a Uniform Resource Identifier (URI) under certain circumstances. Although it is known as URL encoding it is, in fact, used more generally within the main Uniform Resource Identifier (URI) set, which includes both Uniform Resource Locator (URL) and Uniform Resource Name (URN). As such it is also used in the preparation of data of the "application/x-www-form-urlencoded" media type, as is often used in the submission of HTML form data in HTTP requests.

Easy to use

Begin with the "type (or paste) here..." area to enter your data, then hit the "encode" or "decode" buttons respectively. After a blink of any eye, the results will be shown below these buttons. Alternatively, use the "click (or tap) here..." area to select a file from your device, then hit the corresponding button. Once the upload and processing completes, you will be notified to download the resulting decoded/encoded file. That's all!

Completely free

Our tool is free to use. From now you don't have to download any software for such tasks.

Safe and secure

All communications with our servers are made through secure SSL encrypted connections (https). Uploaded files are deleted from our servers immediately after the decode or encode process, and the resulting downloadable file is deleted right after the first download attempt, or 15 minutes of inactivity. We do not keep or inspect the contents of the entered data or uploaded files in any way. Read our privacy policy below for more details.

Details of the URL encoding

Types of URI characters

The characters allowed in a URI are either reserved or unreserved (or a percent character as part of a percent-encoding). Reserved characters are those characters that sometimes have special meaning. For example, forward slash characters are used to separate different parts of a URL (or more generally, a URI). Unreserved characters have no such meanings. Using percent-encoding, reserved characters are represented using special character sequences. The sets of reserved and unreserved characters and the circumstances under which certain reserved characters have special meaning have changed slightly with each revision of specifications that govern URIs and URI schemes.

RFC 3986 section 2.2 Reserved Characters (January 2005)

RFC 3986 section 2.3 Unreserved Characters (January 2005)

Other characters in a URI must be percent encoded.

Percent-encoding reserved characters

When a character from the reserved set (a "reserved character") has special meaning (a "reserved purpose") in a certain context, and a URI scheme says that it is necessary to use that character for some other purpose, then the character must be percent-encoded. Percent-encoding a reserved character involves converting the character to its corresponding byte value in ASCII and then representing that value as a pair of hexadecimal digits. The digits, preceded by a percent sign ("%"), are then used in the URI in place of the reserved character. (For a non-ASCII character, it is typically converted to its byte sequence in UTF-8, and then each byte value is represented as above.)

The reserved character "/", for example, if used in the "path" component of a URI, has the special meaning of being a delimiter between path segments. If, according to a given URI scheme, "/" needs to be in a path segment, then the three characters "%2F" or "%2f" must be used in the segment instead of a raw "/".

Reserved characters after percent-encoding

Reserved characters that have no reserved purpose in a particular context may also be percent-encoded but are not semantically different from those that are not.

In the "query" component of a URI (the part after a ? character), for example, "/" is still considered a reserved character but it normally has no reserved purpose, unless a particular URI scheme says otherwise. The character does not need to be percent-encoded when it has no reserved purpose.

URIs that differ only by whether a reserved character is percent-encoded or appears literally are normally considered not equivalent (denoting the same resource) unless it can be determined that the reserved characters in question have no reserved purpose. This determination is dependent upon the rules established for reserved characters by individual URI schemes.

Percent-encoding unreserved characters

Characters from the unreserved set never need to be percent-encoded.

URIs that differ only by whether an unreserved character is percent-encoded or appears literally are equivalent by definition, but URI processors, in practice, may not always recognize this equivalence. For example, URI consumers shouldn't treat "%41" differently from "A" or "%7E" differently from "~", but some do. For maximum interoperability, URI producers are discouraged from percent-encoding unreserved characters.

Percent-encoding the percent character

Because the percent ("%") character serves as the indicator for percent-encoded octets, it must be percent-encoded as "%25" for that octet to be used as data within a URI.

Percent-encoding arbitrary data

Most URI schemes involve the representation of arbitrary data, such as an IP address or file system path, as components of a URI. URI scheme specifications should, but often don't, provide an explicit mapping between URI characters and all possible data values being represented by those characters.

Binary data

Since the publication of RFC 1738 in 1994 it has been specified[1] that schemes that provide for the representation of binary data in a URI must divide the data into 8-bit bytes and percent-encode each byte in the same manner as above. Byte value 0F (hexadecimal), for example, should be represented by "%0F", but byte value 41 (hexadecimal) can be represented by "A", or "%41". The use of unencoded characters for alphanumeric and other unreserved characters is typically preferred as it results in shorter URLs.

Character data

The procedure for percent-encoding binary data has often been extrapolated, sometimes inappropriately or without being fully specified, to apply to character-based data. In the World Wide Web's formative years, when dealing with data characters in the ASCII repertoire and using their corresponding bytes in ASCII as the basis for determining percent-encoded sequences, this practice was relatively harmless; it was just assumed that characters and bytes mapped one-to-one and were interchangeable. The need to represent characters outside the ASCII range, however, grew quickly and URI schemes and protocols often failed to provide standard rules for preparing character data for inclusion in a URI. Web applications consequently began using different multi-byte, stateful, and other non-ASCII-compatible encodings as the basis for percent-encoding, leading to ambiguities and difficulty interpreting URIs reliably.

For example, many URI schemes and protocols based on RFCs 1738 and 2396 presume that the data characters will be converted to bytes according to some unspecified character encoding before being represented in a URI by unreserved characters or percent-encoded bytes. If the scheme does not allow the URI to provide a hint as to what encoding was used, or if the encoding conflicts with the use of ASCII to percent-encode reserved and unreserved characters, then the URI cannot be reliably interpreted. Some schemes fail to account for encoding at all, and instead just suggest that data characters map directly to URI characters, which leaves it up to implementations to decide whether and how to percent-encode data characters that are in neither the reserved nor unreserved sets.

Common characters after percent-encoding (ASCII or UTF-8 based)

Arbitrary character data is sometimes percent-encoded and used in non-URI situations, such as for password obfuscation programs, or other system-specific translation protocols.
Switch to mobile version