By the end of this lesson you will be able to
- Split a URL into scheme, subdomain, domain, top-level domain, path and query.
- Describe the request and response of an HTTP exchange and read a status code.
- Explain in plain words how HTTPS protects a connection.
- Say what the padlock does not prove about a site.
- Respond sensibly to a browser warning about a certificate.
You use web addresses every day, usually by clicking, rarely by reading them. Learning to read a URL is one of the most useful safety skills there is, because scam links hide in the details. This lesson also shows what really happens between pressing Enter and seeing a page, and why the little padlock matters but is not a guarantee.
Reading a web address
A URL (uniform resource locator) is the full address of one thing on the web: a page, a picture, a file. It is built from parts, read left to right, and each part answers a question: how do I ask for it, which computer holds it, and which item do I want from there?
httpsSchemeHow to ask://SeparatorshopSubdomainA section of the site.dotexample.orgDomain nameWho owns it/books/mathsPathWhich page?page=2QueryExtra detailsRead this figure as text
The address https://shop.example.org/books/maths?page=2 split into labelled parts.
The URL https://shop.example.org/books/maths?page=2 is split into parts. https is the scheme, which says how to ask (a protected connection). :// is the separator. shop is a subdomain, a section of the site. example.org is the registered domain name, which is who owns the site; the last piece, .org, is the top-level domain. /books/maths is the path, which says which page on the server. ?page=2 is the query, extra information sent to the page, here asking for page 2. The domain name is the part to check for safety: it sits just before the first single slash.
A domain name is the human-friendly name of a site, such as example.org. Its last piece, .org, is the top-level domain; others include .com, .edu and country endings such as .ke or .uk. The owner of a domain can create any number of subdomains in front of it, such as shop.example.org or mail.example.org, and these all belong to the same owner.
HTTP: asking and answering
Once DNS has found the server's address, the browser opens a connection and speaks HTTP (Hypertext Transfer Protocol), the set of rules for asking for web content. The exchange is simple. The browser sends an HTTP request, which says what it wants. The server sends back a response with a result and, usually, the content.
Read this figure as text
A sequence diagram of a browser sending a GET request and a server returning a 200 response and a page.
Two actors: the browser and the web server. Message 1, browser to server: GET /books/maths, meaning please send me this page, and also saying which site it is for. Message 2, server to browser: 200 OK, meaning the request worked, followed by the page's HTML. Message 3, browser to server: GET /styles.css, asking for the styling file named in the page. Message 4, server to browser: 200 OK and the styling file. One page often needs many such exchanges, one for each picture, style sheet and script.
The first line of the response holds an status code, a three-digit number saying how it went. You have probably met some of them.
| Code | Meaning | What you might do |
|---|---|---|
| 200 | OK: here is what you asked for | Nothing; it worked |
| 301 or 302 | Moved: look at a different address | Nothing; the browser follows automatically |
| 403 | Forbidden: you are not allowed to see this | Check you are signed in with the right account |
| 404 | Not found: nothing exists at this address | Check the address for typing mistakes |
| 500 | The server has a problem | Wait and try again; it is not your fault |
HTTPS: a private line
Plain HTTP sends everything in readable text. Anyone who can see the traffic along the way, such as someone on the same public Wi-Fi, could read or change it. HTTPS is HTTP carried inside a protected connection created with TLS (Transport Layer Security). TLS gives you three things: privacy because the data is scrambled by Encryption, integrity because changes along the way are detected, and identity because the server proves who it is.
The proof of identity is a Certificate. A trusted organisation checks that whoever asks for a certificate controls the domain, and signs the certificate. Your browser holds a list of trusted organisations and checks the signature. A short, quick agreement then follows, after which both sides use a shared secret key that nobody listening can work out.
Read this figure as text
A sequence diagram of a browser and server agreeing a secure connection using a certificate.
Two actors: the browser and the server for example.org. Message 1, browser to server: Hello, I would like a protected connection. Message 2, server to browser: Hello. Here is my certificate, which says I am example.org. Message 3, browser to server: the browser has checked the certificate (is it signed by someone trusted, is it for this exact domain, has it not expired?) and sends a secret in a way only the server can open; both sides now share a secret key. Message 4, browser to server: the encrypted request. Message 5, server to browser: the encrypted page. Someone watching sees only scrambled data.
- Watcher sees pages and forms
- Content can be changed on the way
- Browser says Not secure
Never type private details.
- Watcher sees only scrambled data
- Changes are detected
- Padlock shown by most browsers
The normal, safe default.
Read this figure as text
A two-column comparison of what a person watching the traffic sees with HTTP and with HTTPS.
HTTP: the address is http://, port 80. A watcher sees the page you asked for, the contents of forms and anything you type, and can change the page on the way. Not suitable for anything private. HTTPS: the address is https://, port 443, with a padlock in most browsers. A watcher sees only that you connected to the server and roughly how much data moved; the pages and anything you type are scrambled. Changes on the way are detected. Use it for everything, and above all for sign-in and payment.
Welcome to the example page
This is an educational simulation of a web page.
- Marker 1: https and a padlock: a protected connection
- Marker 2: Check the domain name too, not just the padlock
Read this figure as text
Two simulated browser windows, one with a padlock and https address and one marked Not secure.
A simulated browser window with the address https://example.org/home (marker 1: the https scheme and the padlock, meaning a protected connection) and the page text Welcome to the example page (marker 2: check the domain, example.org). The browser menu names differ between Chrome, Firefox and others and between releases, so this figure is generic.
When the browser warns you
If a certificate is expired, issued for a different name or not signed by a trusted organisation, the browser stops and shows a full-page warning such as 'Your connection is not private' or 'Warning: Potential Security Risk Ahead'. This is the browser doing its job. For a site you do not run, the safest answer is to go back. A common innocent cause is a computer with the wrong date and time, which makes valid certificates look expired. If the date is correct, do not click through to continue.
Common mistakes
✖ Instead of: Judging a link by its beginning: 'it starts with my bank's name, so it is fine'.
✔ Do this: Find the domain name just before the first single slash and check that it is the real one.
✖ Instead of: Typing a password into any page that says http:// with a Not secure label.
✔ Do this: Only sign in or pay on https:// pages, and only on the real domain.
✖ Instead of: Thinking a 404 error means your internet is broken.
✔ Do this: A 404 arrived from the server, so your internet worked. The page simply is not there at that address.
If something goes wrong
- Every HTTPS site shows a certificate warning.
- Check that your computer's date, time and time zone are correct, then try again. Do not click through warnings on sites where you sign in or pay.
- A page shows a padlock but some pictures are missing or the browser says a part is not secure.
- The page is loading something over plain HTTP. It is the site's fault. Avoid entering private details there and try again later.
Key terms
- Top-level domain (TLD)
- The last part of a domain name, such as .com, .org or .ke.
- Subdomain
- A prefix added to a domain name to name a separate section or service of a site.
- HTTP request
- The message a browser sends to a web server asking for a page or file.
- HTTP status code
- A three-digit number in a server's reply that says whether the request worked.
- Certificate
- A digital document that helps prove a website is really the one named in its address.
Practise it for real
Reading is not the same as being able to do it. Complete these on your own computer, then tick only what you have actually done. These ticks are your own honest record: nothing checks them for you.
Take four addresses apart
On paper, split each address into scheme, subdomain (if any), domain name, path and query, and say who the real owner is: (1) https://mail.example.org/inbox, (2) http://example.com/shop?item=7, (3) https://example.org.login-check.invalid/signin (an educational simulation), (4) https://docs.example.net/guide/start. Then say which one you would not click and why.
Challenge: inspect a connection
On your real computer, open your browser and visit https://example.org. Find the padlock or connection icon beside the address and open it to see what your browser says about the connection and the certificate. Then write a short note: who is the site, is the connection protected, and what do you not know about the site's owner? Menu names vary by browser and release, so explore.
Knowledge check
6 questions. You need 80% to pass. Mistakes here are part of learning, and you can retry as often as you like.
Summary
- A URL has a scheme, domain name (with optional subdomain), path and query; the domain tells you who owns the site.
- HTTP is request and response; the status code tells you how it went.
- HTTPS adds TLS: privacy, integrity and proof of the domain through a certificate.
- The padlock confirms a protected connection, not that the owner is honest.
Checklist: can you do these?
Marking a lesson as read does not prove you can do it. Skills count as demonstrated when you pass the quiz (not yet) and complete the practical tasks (not yet).
Related lessons
References and further reading
Official sources for details that can change between versions.
- What is a URL? (MDN Web Docs)
- An overview of HTTP (MDN Web Docs)
- HTTP response status codes (MDN Web Docs)