Most designers reach for a screenshot when they see a treatment they admire on someone else's site. A screenshot freezes the result and throws away every decision that produced it. The font, the exact hex values, the spacing rhythm, the theme that generated all of it — that information is sitting one keystroke away, in plain text, and you do not need to install a single extension to read it. View Source hands you the raw HTML the server delivered. For a designer, the trick is knowing which fifteen lines of that document actually matter and in what order to read them.

Press Cmd+U on macOS or Ctrl+U on Windows. What follows is the workflow I use to reverse-engineer a design system from that view — typeface first, then color, then the theme fingerprint, then the spacing scale — and the point where the trick stops working and you have to switch tools.

Start with the typeface and the type scale

The fastest win lives in the <head>. Search the source (Cmd+F inside the View Source tab) for fonts.googleapis. A Google Fonts request reads like https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700&display=swap. The family= parameter names the typeface, and the wght@ list tells you exactly which weights the designer loaded — which is itself a design decision. A site pulling only 400 and 600 is making a deliberate two-weight system; one loading five weights is leaning on weight contrast for hierarchy.

If you find no Google Fonts link, search for @font-face or .woff2. Self-hosted fonts show up as preload hints in the head — <link rel="preload" as="font" type="font/woff2"> — and the filename usually leaks the family name. Either way, also look for rel="preconnect" pointing at fonts.gstatic.com; its presence confirms Google Fonts even before you find the stylesheet, and its absence is a strong hint the type is hosted locally.

The WordPress shortcut: read the design tokens directly

Here is the part most "view source" guides miss, and it is specific to where WordPress has gone since the block editor matured. Modern block themes (full site editing, the Twenty Twenty-Two-and-later lineage and countless commercial block themes) inject the site's entire design-token system straight into the source as an inline stylesheet. Search for global-styles-inline-css.

Inside that <style> block you will find the design system written out as CSS custom properties:

--wp--preset--color--* — every named swatch in the palette, with its exact hex or HSL value. This is the color system, handed to you as a list.
--wp--preset--font-size--* — the type scale, named (small, medium, large, x-large) with the actual rem or clamp() values, including any fluid typography.
--wp--preset--spacing--* — the spacing scale that drives the site's vertical rhythm and block gaps.
--wp--preset--font-family--* — the registered font stacks.

For a designer this is close to having the original theme.json file. You are not eyeballing a screenshot to guess whether that heading is 32 or 36 pixels; the value is named and printed. Copy the whole block into your editor and you have a starting palette and scale you can adapt. On a classic theme you will not see this — instead you will find a normal enqueued style.css stylesheet, and you will have to open that file to read the same information the old-fashioned way.

Fingerprint the theme and the build

To learn what generated the design, search the source for wp-content/themes/. The directory name between /themes/ and the next slash is the active theme's folder. Visit https://thatsite.com/wp-content/themes/<name>/style.css directly and you will usually see the theme's header comment block — Theme Name, Author, Version, and often a Theme URI that takes you to where you can buy or download it.

Two more tells confirm you are even looking at WordPress and reveal the rest of the stack:

<meta name="generator" content="WordPress 6.x"> — the default fingerprint, unless the owner stripped it.
wp-content/plugins/<name>/ URLs — these expose the toolset. elementor or et-builder (Divi) tells you a page builder is doing the layout, which changes how you'd interpret the markup. woocommerce, wp-rocket (caching), and wordpress-seo (Yoast) round out a typical commercial stack.

The page-builder signal matters for a designer specifically: if you see Elementor or Divi in the source, the spacing and typography you admired were likely set in the builder's UI, not in theme.json, so the clean token list from the previous section may not exist. You'll be reading inline styles instead.

Read the spacing and layout system

Beyond the named spacing tokens, the head's resource hints tell you how the designer thought about performance, which is itself a design constraint. rel="preload" on a hero image or a critical font signals the team optimized for Largest Contentful Paint — worth noting if you're studying a site that feels fast as well as polished. The <meta property="og:image"> tag, meanwhile, shows you the social-share creative, which often reveals brand colors and the canonical logo lockup at full resolution.

Where the trick stops working

View Source shows you exactly one thing: the HTML the server sent for the URL you visited, before any JavaScript ran. That boundary is where its usefulness ends.

JavaScript-rendered sites. A site built on Next.js, Remix, or Astro that hydrates content client-side will show you a sparse or empty shell in View Source — the real DOM is assembled in the browser after the script runs. The same applies to anything heavy with React. When the source looks suspiciously thin, stop reading it and open Chrome DevTools' Elements panel, which reflects the live, post-hydration DOM. DevTools also gives you the Computed tab and a dedicated Rendered Fonts readout, so you can click any element and see the resolved font, size, and color a screenshot could never tell you.

Anything behind a login. View Source returns the public response. A logged-in dashboard, a members area, or gated content gives you the same markup a logged-out visitor receives, so it is useless for inspecting authenticated UI.

Minified everything. Browsers do not pretty-print minified HTML. Copy the source into VS Code and run a Prettier or Beautify pass; the structure is unchanged, you just get readable indentation.

For a full stack readout when you'd rather not read markup at all, Wappalyzer or BuiltWith will name the CMS, theme, and plugins automatically. But they are a layer of inference on top of the exact thing View Source already shows you for free — and on a WordPress block theme, View Source hands you the actual design tokens, which no detection tool will.

Is reading someone's source allowed?

Yes. Public HTML is, by definition, published — you are reading a file the server chose to deliver to your browser. The legal and ethical line sits at scraping at scale or circumventing access controls, neither of which a single Cmd+U triggers. Studying how a site is built to inform your own work is exactly what an open web format was meant to allow. Just build something of your own from what you learn rather than cloning it wholesale.

The View Source Trick Every Designer Should Know