You're doing a pre-launch image audit and need to confirm every image has an alt attribute, nothing is oversized for its display context, and no placeholder slipped through to production. Doing this manually means right-clicking images one by one, cross-referencing the network tab, and hoping you don't miss anything. The faster way: open the Assets Viewer and extract every asset from the page in one pass — all of them, sorted and filterable.
What gets discovered
The viewer scans the full document — including shadow DOM and iframes — for every media asset on the page:
- Images — all
<img>tags, CSSbackground-imagevalues, and<picture>sources - SVGs — both inline and externally referenced
- Videos —
<video>elements and every source variant - PDFs — embedded via
<embed>,<object>, or direct link - Favicons — all sizes declared in
<link rel="icon">
Filtering by type for different tasks
Use the type filter tabs to zero in on what you need. Researching a competitor's icon system? Switch to SVGs. Auditing page weight? Filter by type to images and sort by file size to find the heaviest ones in seconds.
Downloading website images from Chrome extension
Click the download icon next to any asset to save it directly. SVGs get an extra copy-to-clipboard option — handy when you want to paste the markup into your project instead of managing a standalone file.
URLs as cache-busting indicators
The viewer shows the resolved URL for every asset, including those served from a CDN or behind a rewrite. If the URL contains a content hash, the asset is properly cache-busted. If it's a plain filename with no hash, it might be serving a stale version in production.
Practical use cases
Competitive design research
Load a competitor's site, open the Assets Viewer, filter to SVGs, and see which icon library they're using. You'll often spot Heroicons, Lucide, or a custom set immediately from the SVG path structure — no guessing, no reading minified source.
Pre-launch image audit
Before shipping a new page, scan its assets to confirm: every image has an alt attribute (visible in the list), no images are obviously oversized for their display context, and WebP is being served where JPEG used to be.
Client QA session
During a client review, use the Assets Viewer to confirm the right brand assets landed in production — logo at the correct resolution, favicons in all required sizes, no placeholder images that slipped through the deploy.
Images and media make up the bulk of most pages' total payload. A clear inventory of every asset on a page is the first step toward making that payload smaller.
Page weight budgets and the Assets Viewer
Performance budgets — targets for how much a page is allowed to weigh — are only enforceable when you can actually see everything that's loading. Under 1MB compressed is a reasonable starting baseline for most pages. But setting a budget is one thing. Knowing which assets are blowing it is another.
The Assets Viewer shows file sizes for each discovered asset. Sort by size and the problem becomes obvious immediately. That 2MB hero image that should be 150KB. The 40MB MP4 in the background of the pricing section that should be a compressed WebP video loop or, better yet, a YouTube embed. You can't optimize what you can't see, and the network tab alone doesn't give you this kind of organized, filterable view of the full asset inventory.
We built the Assets Viewer into onHover specifically because the network tab was doing too much. It mixes API calls, fonts, scripts, stylesheets, and media into one undifferentiated stream. Filtering out everything except images takes time. Finding the heaviest image takes more time. The Assets Viewer cuts that entire workflow down to a few seconds.
The move that really unlocks the budget picture: combine the Assets Viewer with onHover's Network Throttle set to Slow 3G. The throttle shows you how long the page actually takes to load for users on constrained connections. The Assets Viewer shows you exactly which assets are responsible for that wait time. The combination is more useful than either tool alone — you get both the symptom (slow load on 3G) and the cause (that uncompressed 4MB image in the carousel).
Quick weight budget check
Sort the Assets Viewer by file size descending. Anything in the top 5 that isn't a video is worth investigating. Images over 500KB serving at display sizes under 800px wide are almost always over-compressed originals that were never resized for web delivery.
Finding the right image format for each asset type
Format compliance is one of those audits that feels tedious until you do it once on a production site and find a 3MB PNG serving where a 200KB WebP should be. The Assets Viewer shows the URL — and therefore the file extension — for every image on the page. That's your format audit, right there.
Here's what we look for when scanning formats:
- JPEGs that should be WebP — WebP gives 25–35% smaller files at equivalent visual quality. Any JPEG that isn't a user-uploaded photo or legacy export is a candidate for conversion.
- PNGs that should be WebP or AVIF — especially images with transparency. WebP supports alpha channel. AVIF goes further on supported browsers (Chrome, Firefox, Safari 16+). A PNG served where WebP would work is leaving compression on the table.
- SVGs being served as rasterized PNGs — logos and icons that exist as SVGs but are being exported as PNGs lose their infinite scalability and arrive heavier than necessary. Spot them by looking for small, blocky icons in the Images filter that should clearly be vector.
- GIFs that should be videos — MP4 encodes of the same animation are dramatically smaller. A 5MB GIF is often a 200KB MP4. Always. Every time.
A quick Assets Viewer scan on any page shows the full format picture at a glance. No network tab filtering, no manual DOM inspection. Load the page, open the onHover Chrome extension, switch to the Assets Viewer, filter to Images — you have everything you need in about ten seconds.
The favicon completeness check for PWAs
Progressive web apps have specific favicon size requirements, and missing even one of them produces a noticeably degraded experience on the platform that needs it. The OS doesn't gracefully handle missing sizes — it scales up whatever it has, and a blurry home screen icon is the kind of detail that makes a product feel unfinished.
The sizes that matter:
- 16×16 — browser tab
- 32×32 — Windows taskbar and bookmark icons
- 180×180 — Apple Touch Icon for iOS home screen
- 192×192 — Android home screen
- 512×512 — Android splash screen and high-DPI contexts
The Assets Viewer's Favicons filter lists every icon size declared in your document's link tags, pulled directly from the markup. You can see in one glance whether the full set is declared. If the 512×512 is missing, you find out before launch rather than after a user screenshots a blurry splash screen and files a bug report.
We've run this check on dozens of sites — including our own — and it's remarkable how often a favicons set is almost right but missing the 180×180 or the 512×512. Adding missing sizes to a manifest is a five-minute fix. Finding out they're missing before users do is the win.
Video audit: autoplay, format, and compression
Hero videos are a reliability risk. Done right, they add atmosphere without penalty. Done wrong — wrong format, no poster, oversized source file — they tank LCP scores, introduce cumulative layout shift on slow connections, and chew through mobile data budgets for users who didn't ask for a video experience.
The Assets Viewer surfaces every video element on the page alongside its source URL. That URL tells you the format immediately. For each hero video, we check three things:
Format and codec. MP4 with H.264 is fine for compatibility, but H.264 at 1920×1080 at 30fps is often 10× larger than it needs to be. H.265 halves the file size for equivalent quality. WebM/VP9 is another strong option for browsers that support it. The format in the URL tips you off immediately — a .mp4 URL doesn't tell you the codec, but it at least confirms whether someone tried to serve a modern format.
File size. A hero background video over 5MB on a 3G connection takes 60 seconds or more to fully buffer. Most users won't wait. They'll experience either a blank section or a layout jump when the video finally loads. The Assets Viewer shows the file size next to the URL. Anything over 2MB for a background loop is worth flagging for compression review.
Poster attribute. If a video doesn't have a poster frame set, browsers show a blank space until the first video frame decodes. That blank flash is both a CLS hit (if it causes layout shift) and a bad first impression. The Assets Viewer shows the element attributes alongside the source URL, so you can confirm the poster is set without opening the DOM inspector.
Seeing the asset URL, the element attributes, and the file size together in the Assets Viewer makes video audits significantly faster than cross-referencing the network tab with the DOM inspector. That cross-referencing is exactly the kind of friction that causes video issues to slip through pre-launch checklists. The onHover developer toolkit removes that friction by putting everything in one place.