Guides
How to View a Page's Source Code (2026): Every Browser, and What to Look For
On this page
On Windows and Linux it’s Ctrl + U. On a Mac it’s Cmd + Option + U. That’s the whole answer to the question most people are asking. But there’s a second, more useful thing to know: what you see with Ctrl + U is not what you see in DevTools, and the difference between those two views is the single most common source of confusion when someone is debugging why a page isn’t ranking. Here’s both — the shortcuts, and what to actually do with them.
The shortcut, in every browser
| Browser | Windows / Linux | macOS |
|---|---|---|
| Chrome | Ctrl + U |
Cmd + Option + U |
| Firefox | Ctrl + U |
Cmd + Option + U |
| Edge | Ctrl + U |
Cmd + Option + U |
| Brave / Opera / Vivaldi | Ctrl + U |
Cmd + Option + U |
| Safari | — | Cmd + Option + U (see below) |
You can also right-click anywhere on the page and choose View Page Source (Chrome, Firefox, Edge) or Show Page Source (Safari).
The view-source: prefix
Every desktop browser supports typing the URL directly:
view-source:https://example.comThis is the one worth remembering, because it works when right-click is disabled — which some sites do, and which stops precisely nobody.
Safari needs one setting turned on first
Safari hides its developer tools by default. Once, and then never again:
- Safari → Settings (or Preferences)
- Advanced tab
- Tick Show features for web developers (older versions: Show Develop menu in menu bar)
The Develop menu appears, and Cmd + Option + U starts working.
The part that actually matters: raw vs rendered
This is the distinction that separates “I looked at the source” from “I know what Google sees”.
Ctrl + U shows you the raw HTML — the exact bytes the server sent, before any JavaScript ran.
DevTools → Elements shows you the rendered DOM — the live document after JavaScript has executed, elements have been injected, and frameworks have done their work.
On a plain HTML site they look nearly identical. On a React, Vue, Next.js or Angular site they can be dramatically different: view-source might show you an almost-empty <div id="root"></div> while the Elements panel shows a full page of content.
Why this matters for SEO: Google does render JavaScript, but rendering is a second pass that happens on Google’s schedule, not instantly. Content that exists only after JS runs is at the back of a queue. And many other crawlers — including several AI crawlers — render little or no JavaScript at all, so for them, raw HTML is the entire page. I’ve written about what that means for technical SEO in the AI era and which AI crawlers exist.
The test to run: open view-source: on your own page and use Ctrl + F to search for a sentence from your main content. If it isn’t there, that content is client-side rendered — and you should know that about your own site.
Opening DevTools (when you need the rendered view)
| Action | Windows / Linux | macOS |
|---|---|---|
| Open DevTools | F12 or Ctrl + Shift + I |
Cmd + Option + I |
| Inspect a specific element | Ctrl + Shift + C |
Cmd + Option + C |
| Open the Console | Ctrl + Shift + J |
Cmd + Option + J |
Right-click any element and choose Inspect to jump straight to it in the Elements panel. That’s usually faster than scrolling the source.
Viewing source on mobile
Android (Chrome): view-source: works. Type it before the URL in the address bar.
iOS (Safari): there’s no native view-source. Three real options:
- Connect to a Mac. Enable Web Inspector in Settings → Safari → Advanced, plug the phone in, and open Safari → Develop → your device on the Mac. This is the proper way — you get full DevTools against the live mobile page.
- Use a third-party browser from the App Store that includes a source viewer.
- Just use desktop with device emulation in DevTools (the toggle-device-toolbar icon). For most checks this is genuinely sufficient and far quicker.
What an SEO actually looks for in the source
Once the source is open, Ctrl + F is your friend. The checks I run most:
<title>— is it there, is it what you intended, is it unique?<meta name="description">— present, and roughly under 160 characters<link rel="canonical">— searchcanonical. This is the one that quietly breaks things: a page canonicalising to the wrong URL removes itself from the index. See duplicate, Google chose a different canonical.<meta name="robots">— searchnoindex. Finding it where you didn’t expect it explains a lot of missing pages. Related: noindex vs disallow and the header-based X-Robots-Tag.application/ld+json— your structured data. If it’s malformed, see unparsable structured data.hreflang— if you run multiple languages, check the return tags match (hreflang no return tags).<h1>— search<h1. More than one, or none at all, is worth knowing about.og:tags — what gets pulled when someone shares the link.
One caveat on checking robots meta this way: a noindex can also be delivered as an HTTP header rather than in the HTML, in which case it won’t appear in view-source at all. If a page is behaving as though it’s noindexed but the source looks clean, check the response headers in DevTools → Network.
Why “view source” is still worth knowing
It’s the fastest honest answer to “what is this page actually telling search engines?” — no tool, no login, no crawl budget, no waiting. Every SEO audit tool is ultimately reporting on things you can read yourself in ten seconds, and being able to check directly is what stops you taking a tool’s word for something it got wrong.
If practical technical notes like this are useful, I send them occasionally — subscribe below, and grab the free GEO Starter Checklist while you’re there.
Related reading: technical SEO in the AI era covers what changes when AI crawlers are in the mix, X-Robots-Tag covers directives that live in headers rather than HTML, and AI crawler user agents lists who’s actually fetching your pages.
Frequently asked questions
How do I view the source code of a web page?
Press Ctrl + U on Windows or Linux, or Cmd + Option + U on macOS. You can also right-click the page and choose View Page Source, or type view-source: immediately before the URL in the address bar. All three show the raw HTML the server sent.
How do I view source code in Safari?
Safari hides developer features by default. Open Safari → Settings → Advanced and tick "Show features for web developers" (called "Show Develop menu in menu bar" in older versions). After that, Cmd + Option + U opens the page source and the Develop menu appears in the menu bar.
What is the difference between view-source and Inspect Element?
View-source shows the raw HTML exactly as the server sent it, before any JavaScript runs. Inspect Element (DevTools → Elements) shows the rendered DOM — the live document after JavaScript has executed. On JavaScript-heavy sites these can look completely different, and the raw HTML is what non-rendering crawlers see.
How do I view page source on an iPhone?
iOS Safari has no built-in view-source. The reliable method is connecting your iPhone to a Mac: enable Settings → Safari → Advanced → Web Inspector, then use Safari → Develop → your device on the Mac. Alternatively use a third-party iOS browser with a source viewer, or check from a desktop browser using device emulation.
Why can I not right-click to view source on some sites?
Some sites disable the right-click context menu with JavaScript. It does not actually protect anything — the HTML has already been sent to your browser. Use the keyboard shortcut or the view-source: URL prefix instead, both of which bypass it entirely.
How do I check if my content is client-side rendered?
Open view-source: on your page and use Ctrl + F to search for a distinctive sentence from your main content. If the text does not appear in the raw HTML but is visible on the page, that content is rendered by JavaScript in the browser — which means non-rendering crawlers will not see it.