URL Validator

• Step 1: Type or paste the URL you want to validate into the input field. Use a full URL that includes the protocol, for example https://example.com/path?query=value#fragment. A URL without a protocol (such as example.com/page) is not a complete URL and will be reported as invalid.

• Step 2: Read the validity result. The result updates instantly as you type, so there is no need to press a button. A valid URL passes the format check, confirming it is correctly structured. An invalid URL receives an error message describing what is wrong.

• Step 3: Review the structural breakdown. For a valid URL, the tool shows the protocol, the domain, the path (when the URL has one beyond the root), and each query parameter as a separate key and value pair.

• Step 4: Check the connection status. URLs that use https are marked as a secure connection. URLs that use http are marked as unsecured, because the data is not encrypted in transit.

• Step 5: Use the breakdown. This is useful when debugging API calls with long query strings, verifying that a path is correctly formed, or understanding the structure of an unfamiliar URL. The sections below also explain the components the breakdown does not display, such as the port, the userinfo, and the fragment.

What this validator checks

The validator confirms that the URL string can be parsed as a complete, absolute URL. It uses the browser's built-in URL parsing engine, which follows the WHATWG URL Standard (built on the same foundations as RFC 3986) and is the same parser your browser uses when it navigates to a link.

What this validator does not check

This tool validates format and structure only. It does not confirm that the URL is reachable, that the server at the domain is online, that the specified path returns a valid response, or that the resource at the URL exists. Format validation confirms correct structure. Reachability verification requires an actual HTTP request to the URL.

Browser URL parsers are also more forgiving than the strict specification in some places. For example, they may quietly encode a space in a path instead of rejecting it. A URL that the parser accepts can therefore still be rejected by a stricter system, so always write URLs in their fully encoded form.

A complete URL can contain up to seven distinct components. Understanding each one helps you interpret the structural analysis the validator provides and write correct URLs from the start. The general structure of a URL is:

scheme://userinfo@host:port/path?query#fragment

Not every URL contains all seven components, but each one that appears must follow specific rules.

1. Scheme (Protocol)

The scheme identifies the protocol used to access the resource. It appears before the colon and double slash (://). Common schemes:

• https: HyperText Transfer Protocol Secure. The standard scheme for all modern websites. Data transmitted is encrypted using TLS.

• http: HyperText Transfer Protocol (unencrypted). Still encountered, but browsers mark http sites as "Not Secure."

• ftp: File Transfer Protocol, used for file transfers.

• mailto: Opens the user's email client for composing an email.

• tel: Opens a phone dialing interface.

• file: References a file on the local filesystem.

• data: Embeds small data directly in the URL (data URIs).

Rules: the scheme must start with a letter, followed by any combination of letters, digits, plus signs, hyphens, or dots. It must be followed by a colon. Schemes are case-insensitive in practice (HTTP and http are treated identically by browsers) but are conventionally written in lowercase.

Valid schemes: https://, http://, ftp://, mailto:, tel:

2. Userinfo (Authentication)

The userinfo component appears after the scheme and before the @ symbol: username:password@host. This component is rarely used in modern URLs because embedding credentials in a URL is a significant security risk (the URL appears in browser history, server logs, and referrer headers in plain text). It appears most often in FTP URLs and some internal development tools.

Valid example: ftp://user:password@ftp.example.com (avoid this in production)

3. Host (Domain or IP Address)

The host is the address of the server where the resource is located. It appears after the :// (or after the @ if userinfo is present). The host can be:

• A domain name: example.com, www.example.com, subdomain.example.co.uk

• An IP address: 192.168.1.1

• An IPv6 address in square brackets: [2001:db8::1]

Domain name rules are the same as for the domain part of an email address. Labels are separated by dots, each label contains only letters, digits, and hyphens, does not start or end with a hyphen, and is between 1 and 63 characters long. The full domain must not exceed 253 characters. The final label is the TLD (top-level domain).

4. Port

The port number specifies which network port on the server to connect to. It appears after the host, separated by a colon: host:port. Most URLs do not include an explicit port because each scheme has a default port:

• https: default port 443

• http: default port 80

• ftp: default port 21

When the default port is used, it is omitted from the URL. When a non-standard port is used, it must be included: https://api.example.com:8443/endpoint. Port numbers must be integers between 0 and 65535.

5. Path

The path identifies the specific resource on the server. It appears after the host (and optional port), starting with a forward slash. A path consists of segments separated by forward slashes. Each segment can contain letters, digits, hyphens, underscores, tildes, dots, and percent-encoded characters for anything else.

Valid paths: /, /about, /products/category/item, /api/v2/users/123

Rules:

• Paths can be empty (the root of the domain is an empty path, implicitly /).

• Paths use forward slashes as separators. Backslashes are not valid path separators in URLs.

• Consecutive forward slashes (//) are technically valid in paths but may have special meaning in some URL resolution contexts.

• Dots in paths have special meaning: a single dot (.) refers to the current directory and a double dot (..) refers to the parent directory.

6. Query String

The query string passes data to the server or application as key-value pairs. It begins with a question mark (?) after the path and consists of parameter=value pairs separated by ampersands.

Example: https://example.com/search?q=URL+validator&category=tools&page=2

Breaking down this query string:

• q=URL+validator: first parameter, q with the value "URL validator" (space encoded as +)

• category=tools: second parameter, category with the value "tools"

• page=2: third parameter, page with the value "2"

Rules for query strings:

• Parameter names and values should be percent-encoded if they contain characters outside the unreserved set (letters, digits, hyphen, dot, underscore, tilde).

• Spaces can be encoded as %20 or as + in query strings (+ encoding is a legacy convention from HTML form submissions).

• The order of parameters is not specified by the URL standard, but applications may treat parameter order as meaningful.

• Duplicate parameter names are technically allowed (the query string category=a&category=b has two values for "category") and many web frameworks parse these as arrays. Because the breakdown in this tool lists each parameter name once, only one value is shown for a repeated name.

7. Fragment (Hash)

The fragment identifier specifies a specific section within the resource. It begins with a hash character (#) and appears at the very end of the URL. For example, in https://example.com/documentation#installation the fragment "installation" instructs the browser to scroll to the element with the id "installation" after loading the page.

Critical distinction: the fragment is never sent to the server. Browsers strip the fragment before making the HTTP request. The fragment is processed entirely by the browser after the page loads. This means server-side code never sees the fragment, and the server cannot use it for routing (unless client-side JavaScript is used to read window.location.hash and handle routing).

This has important implications for single-page applications (SPAs) that use hash-based routing (#/home, #/about) and for URL sharing where the fragment contains important navigation context.

• Missing scheme. The URL has no scheme (no https://), so it is not a complete URL. Invalid: example.com/page. Valid: https://example.com/page

• Mistyped scheme. A typo such as htp://example.com is a different scheme from http. Parsers may accept it as a syntactically valid but unknown scheme, and browsers will not know how to open it. Always double-check that the scheme is spelled correctly.

• Missing host. The URL has a scheme but no host following it. Invalid: https:// (no host after ://). Valid: https://example.com/path

• Invalid characters in the domain. Spaces and many symbols are not allowed in a host. Invalid: https://exam ple.com (space in domain). Underscores (https://example_site.com) and labels that start or end with a hyphen (https://-example.com) break the standard domain naming rules, so some parsers accept them while DNS and stricter validators do not. Valid: https://example-site.com (hyphen inside a label).

• Invalid port number. The port is outside the valid range or contains non-numeric characters. Invalid: https://example.com:99999 (port above 65535) and https://example.com:abc (non-numeric port). Valid: https://example.com:8080

• Unencoded special characters in the path or query. Characters that require percent-encoding appear unencoded. A path such as https://example.com/page with spaces should be written as https://example.com/page%20with%20spaces. Some parsers silently fix this for you, but other systems will reject the raw form.

• Malformed query string. The query string has structural problems, such as a missing = or stray ampersands. Many validators accept loosely formed query strings, so check the parameter list in the breakdown to confirm each key and value is what you expect.

• Missing closing bracket on an IPv6 address. IPv6 addresses in URLs must be enclosed in square brackets. Invalid: https://[2001:db8::1/path. Valid: https://[2001:db8::1]/path

URL encoding, also called percent encoding, is the mechanism for including characters in a URL that would otherwise be ambiguous or invalid in that position. A percent-encoded character is represented as a percent sign (%) followed by two hexadecimal digits representing the character's byte value.

Why encoding is necessary

Certain characters have reserved meanings in URLs: / separates path segments, ? begins the query string, # begins the fragment, & separates query parameters, = separates parameter names from values, and : separates the scheme from the host and the host from the port. If these characters appear in a value (such as a search query containing a question mark), they must be encoded to avoid being interpreted as URL syntax.

Common percent-encoded characters

• Space: %20 (or + in query strings)

• Exclamation mark !: %21

• Hash #: %23 (when in a path or query, not the fragment position)

• Dollar sign $: %24

• Ampersand &: %26 (when in a value, not a query separator)

• Plus sign +: %2B (when a literal plus is intended, not a space)

• Forward slash /: %2F (when in a value, not a path separator)

• Colon :: %3A

• Equals sign =: %3D (when in a value, not a separator)

• Question mark ?: %3F (when in a value)

• At sign @: %40

Unreserved characters that do not need encoding

Letters (A through Z, a through z), digits (0 through 9), hyphen (-), underscore (_), tilde (~), and dot (.) never need to be percent-encoded and can appear literally in any part of a URL.

International characters

URLs technically only support ASCII characters in their standard form. International domain names (IDNs) that contain non-ASCII characters (like café.com) are handled through the Punycode encoding system, which converts Unicode domain labels to ASCII-compatible equivalents (strings with an xn-- prefix). Non-ASCII characters in paths and query strings must be UTF-8 encoded and then percent-encoded.

Understanding the distinction between absolute and relative URLs is important when using a URL validator, because the two forms have different validity criteria.

Absolute URLs

An absolute URL contains all the information needed to locate a resource without any context: scheme, host, and usually a path. The validator confirms an absolute URL is complete and correctly structured.

• https://www.example.com/about

• https://api.example.com/v2/users?active=true

• ftp://files.example.com/report.pdf

Relative URLs

A relative URL omits the scheme and host and is interpreted relative to the current document's URL. They appear in HTML, CSS, and other documents but are not independently meaningful without the context of a base URL.

• /about (root-relative: starts with / on the same domain)

• about.html (document-relative: in the same directory)

• ../images/logo.png (parent directory reference)

• ?page=2 (query-only: same path, different query)

• #section (fragment-only: same page, different position)

A relative URL by itself is not a complete URL. A URL validator for complete URLs will report relative URLs as invalid. This is correct behavior: /about is not a complete URL without knowing its base.

Protocol-relative URLs

A protocol-relative URL begins with // and omits the scheme, inheriting it from the current page's protocol. For example, //example.com/resource.js uses the same scheme as the page loading it. Protocol-relative URLs are technically valid but discouraged in modern practice. Since virtually all sites now serve over HTTPS, explicitly writing https:// is preferred over the protocol-relative form.

Web development contexts

URLs appear throughout web development: HTML href and src attributes, CSS url() functions, JavaScript fetch() calls and XMLHttpRequest, HTTP redirect targets, API endpoint definitions, and configuration files. A malformed URL in any of these contexts produces failures that can be difficult to diagnose. The URL validator helps confirm that URLs are correctly formed before they are embedded in code or data.

Canonical URLs

In SEO, canonical URLs tell search engines which version of a URL is the definitive one when multiple URLs serve the same content. A canonical tag with a malformed URL (missing scheme, incorrect format) is ignored by search engines, defeating its purpose. Validating canonical URL values before publishing ensures the tag works as intended.

URL parameters and SEO

Query parameters in URLs (the ?key=value portion) are used by web applications for filtering, sorting, pagination, and tracking. Search engines crawl and index URLs with parameters but may treat different parameter combinations as separate pages, causing duplicate content issues. Understanding URL structure through validation and analysis helps SEO practitioners and developers implement parameter handling correctly.

Redirects

HTTP redirects (301 permanent, 302 temporary, 307, and 308) require valid destination URLs. A redirect to a malformed URL typically produces an error page or unexpected behavior. Validating redirect destination URLs before implementing them prevents broken redirect chains.

Sitemaps

XML sitemaps submitted to search engines contain lists of URLs to crawl. URLs in sitemaps must be absolute (complete with scheme and domain) and correctly formatted. Invalid URLs in sitemaps are ignored by search engines.

Thetoolity brings together a growing collection of free, fast, and clean online tools for developers, SEO professionals, data analysts, and anyone who works with links, APIs, and web addresses. Our URL validator checks format using the browser's own URL parsing engine and provides a structural breakdown that helps you understand not just whether a URL is valid but what each part of it means.

No accounts. No subscriptions. No cluttered interfaces. No data stored. Just a clean, instant URL validity check with structural analysis.

Explore the full collection at Thetoolity.com and find generators, converters, calculators, checkers, and testers, all free and all instant.