In Part 1 you learned HTML’s basic anatomy, and in Part 2 you learned how to structure text with headings and semantic elements. Now we get to the feature that gave HTML its name in the first place: hyperlinks. Without links, every page you build would be an isolated island — links are what turn a pile of documents into “the web.” This lesson covers the anchor element thoroughly: how URLs actually work, every practical linking pattern you’ll use, and the accessibility details that separate professional link markup from amateur markup.
The anchor element: HTML’s link tag
Every link in HTML is built from the <a> element (“anchor” — a name inherited from early hypertext systems), combined with an href attribute (“hypertext reference”) pointing at a destination:
<a href="https://developer.mozilla.org">MDN Web Docs</a>
Everything between the opening and closing <a> tags becomes the clickable link text — and importantly, it doesn’t have to be plain text. It can wrap an image, a heading, or several nested elements, all of which become part of one clickable region:
<a href="/product/42">
<img src="shoe.jpg" alt="Blue running shoe">
<span>Running Shoe – $59</span>
</a>
Understanding URLs: the anatomy of a web address
Before we cover different kinds of links, it’s worth breaking down exactly what’s inside a URL (Uniform Resource Locator), since every href value is one:
You’ll rarely need to type a port number (browsers assume 443 for https:// and 80 for http://), but understanding that a URL is a structured address with distinct parts — not just “a string” — makes the rest of this lesson, and later lessons on routing in JavaScript frameworks, much easier to reason about.
Absolute vs. relative URLs
This is the distinction that trips up more beginners than anything else in this lesson. An absolute URL includes the full address, scheme and all:
<a href="https://codebookcentral.com/blog/html-basics-part-1">Part 1</a>
A relative URL omits the scheme and host, and is resolved relative to the current page’s own URL:
<!-- If the current page is https://codebookcentral.com/blog/part-2 -->
<a href="part-3">Next lesson</a>
<!-- resolves to https://codebookcentral.com/blog/part-3 -->
<a href="/about">About us</a>
<!-- a leading slash means "from the site root" -->
<!-- resolves to https://codebookcentral.com/about, regardless of current path -->
<a href="../images/logo.png">Logo</a>
<!-- ".." means "go up one folder level" first -->
Use relative URLs for links within your own site — if you ever move your site to a new domain, none of your internal links need to change. Use absolute URLs when linking to a different site entirely, since a relative URL has no way to point outside the current domain.
Linking to a specific spot on the same page
Fragments (the # part of a URL) let you link directly to a specific element on a page, using that element’s id attribute as the target:
<!-- Somewhere earlier on the page: a table of contents -->
<nav>
<a href="#ingredients">Jump to Ingredients</a>
<a href="#instructions">Jump to Instructions</a>
</nav>
<!-- Further down the same page: -->
<h2 id="ingredients">Ingredients</h2>
<p>...</p>
<h2 id="instructions">Instructions</h2>
<p>...</p>
Clicking “Jump to Ingredients” scrolls the browser straight to the element whose id="ingredients", with no page reload. This pattern powers every “table of contents” or “back to top” link you’ve ever clicked, and it also works across pages — href="/recipes/pasta#instructions" loads that page and scrolls straight to the instructions section, combining a path and a fragment in one link.
Opening links in a new tab — and doing it safely
The target="_blank" attribute opens a link in a new tab or window:
<a href="https://external-site.com" target="_blank">Visit external site</a>
This alone has a real, historically significant security problem: the newly opened page gets partial access to the original page’s window object via JavaScript’s window.opener reference, which a malicious destination page could theoretically use to redirect your original tab to a phishing page while you’re looking at the new one (“tabnabbing”). The fix is a second attribute, rel="noopener", which severs that connection:
<a href="https://external-site.com" target="_blank" rel="noopener">
Visit external site
</a>
Modern browsers have actually made noopener the implicit default behavior for target="_blank" links since around 2021, but writing it explicitly is still considered best practice, both for older browser support and for clarity when someone else reads your code. You’ll often also see rel="noreferrer" added alongside it, which additionally stops the browser from sending your page’s URL as the “referrer” header to the destination site — useful when you don’t want the linked site to know where the click came from.
Email and phone links
The href attribute isn’t limited to web addresses. Two other schemes are extremely common:
<a href="mailto:hello@example.com">Email us</a>
<a href="mailto:hello@example.com?subject=Support%20Request">
Email support (pre-filled subject)
</a>
<a href="tel:+15551234567">Call us: (555) 123-4567</a>
Clicking a mailto: link opens the visitor’s default email application with the “To” field (and optionally subject, via ?subject=..., URL-encoded) pre-filled. Clicking a tel: link on a phone offers to dial the number directly — genuinely useful on mobile, essentially inert (but harmless) on a desktop with no calling capability.
The download attribute: linking to a file to save, not view
Normally, clicking a link to a PDF or image opens it in the browser. Adding download tells the browser to save the file to disk instead:
<a href="/files/annual-report.pdf" download>Download the report (PDF)</a>
<a href="/files/annual-report.pdf" download="2025-report.pdf">
Download as "2025-report.pdf"
</a>
Giving download a value (as in the second example) lets you suggest a filename different from the one on the server — handy when your server-side filename is something unfriendly like report_v3_FINAL_final2.pdf.
Writing accessible link text
This section matters as much as the syntax above, and it’s the part most tutorials skip. Screen readers commonly offer a feature that lists every link on a page out of context, as a standalone list, so users can jump straight to the one they want. That means link text needs to make sense entirely on its own, disconnected from its surrounding sentence:
<!-- Bad: meaningless out of context -->
<p>Our new pricing is now live. <a href="/pricing">Click here</a> to view it.</p>
<!-- Good: makes sense standalone -->
<p>Our new pricing is now live. <a href="/pricing">View our new pricing</a>.</p>
If a screen reader user pulls up a list of every link on that first version’s page, they’ll see a list full of entries that just say “Click here,” “Click here,” “Read more,” over and over, with zero indication of where any of them actually go. The second version’s link list is immediately scannable and meaningful on its own. As a rule: a link’s visible text should describe its destination, not the act of clicking.
Broken links and the importance of correct paths
A link pointing at a URL that doesn’t exist results in a 404 Not Found response from the server (we’ll cover HTTP status codes properly in a later lesson on forms and HTTP). The most common causes for beginners are typos in relative paths, case-sensitivity mismatches (many servers treat /About and /about as different paths), and forgetting that a relative path’s meaning depends entirely on the current page’s own location, as shown in the absolute-vs-relative section above. When in doubt while learning, absolute URLs are more forgiving because they don’t depend on where the link lives.
Recap
This lesson covered: the anchor element and how it can wrap more than plain text; the structural anatomy of a URL (scheme, host, port, path, query, fragment); the critical difference between absolute and relative URLs and when to use each; linking to a specific spot on a page (or another page) using fragments and id attributes; safely opening links in a new tab with target="_blank" and rel="noopener"; mailto: and tel: links; the download attribute for forcing a file save; and why accessible, standalone-meaningful link text matters for screen reader users.
Coming up next: Part 4 will cover images and media — the <img> element, writing genuinely useful alt text, responsive images with srcset, and embedding audio and video natively with <audio> and <video>.
