Short answer
- The protocol tells the browser how to access the resource, usually https.
- The host identifies the domain and optional subdomain.
- The path points to a page or resource, while the query string carries key-value parameters.
- The fragment starts with # and is usually handled by the browser or page script.
Main URL parts
| Part | Example | What it means |
|---|---|---|
| Protocol | https: | How the browser should access the resource |
| Host | example.com | The domain or subdomain |
| Path | /tools/url-parser | The page or resource location |
| Query string | ?utm_source=newsletter | Parameters sent after the path |
| Fragment | #pricing | A page section or client-side state marker |
Query parameters
Query parameters are key-value pairs after the question mark. Multiple parameters are separated with ampersands.
The same key can appear more than once. That is valid URL syntax, but different systems handle repeated keys differently.
https://example.com/search?q=timestamp&sort=newest&utm_source=email
Encoded values
Spaces, ampersands, equal signs, and non-ASCII characters often need URL encoding inside query values.
Decode a value when you need to read it. Encode a value before placing it back into a URL.
UTM campaign values
UTM parameters are regular query parameters with agreed names such as utm_source, utm_medium, and utm_campaign.
Parse a finished URL to audit the actual query string, then use a UTM builder when you need consistent campaign links.
FAQ
Does parsing a URL visit the website?
No. URL parsing can split the text into parts without fetching the remote page.
Are query parameters always sent to the server?
Usually yes, but client-side apps can also read and change them in the browser. Fragments after # are not sent in normal HTTP requests.
Should UTM values be URL encoded?
Yes. Campaign values that contain spaces or special characters should be encoded so the URL remains valid.