Device Dashboard: Screen Resolution & Device Info Checker

Open this page and the numbers are already there. No button to press, no setup, no loading animation. Resize the window or rotate your phone and they update live — screen resolution, viewport size, device pixel ratio, browser name and version, operating system, color depth, orientation. All of it, instantly, without you doing anything.

The reason this page exists usually starts the same way: someone says a layout "looks weird" on their phone, and you have no idea what phone, what browser, or what size they're actually looking at. You ask. They say "iPhone." Cool, but which one? With what browser? In portrait or landscape? With zoom set to something non-default? Now you're three messages deep in a Slack thread and still guessing. Instead of that, you send them this link and ask for a screenshot. Now you've got the exact resolution, DPR, and browser version in one image instead of three separate guesses that might all be wrong.

I've been in that exact conversation more times than I can count. The worst version is when someone sends a screenshot and you can see the layout is broken, but you can't tell whether it's a viewport issue, a DPR issue, a browser-specific rendering bug, or something else entirely. The Device Dashboard doesn't fix bugs for you, but it removes the guesswork from figuring out which direction to look in. That alone saves real time.

It's also useful on the QA side of things. If you're testing whether a responsive breakpoint fires where you expect, this confirms the actual viewport width you're at in real time. You're not trusting a spec sheet number for a device that might not match what the browser itself is reporting — especially once browser zoom or an unusual window size gets involved. I've seen situations where a developer tests on what they think is a 375px-wide viewport, the breakpoints behave exactly as expected, and then the bug turns out to only happen at 374px or 376px because the zoom was slightly off. This dashboard catches that kind of thing immediately.

Screen size and viewport size are not the same thing

This trips people up constantly, and it's one of those things that seems obvious once you get it but causes real confusion before that point.

Screen resolution is a fixed hardware fact — the literal pixel count of the display, set at manufacture. Your phone's spec sheet says 1170 by 2532 or whatever, and that number doesn't change. Viewport size is the space your browser window actually gives to the page, after toolbars, tabs, and system chrome eat into it. It changes depending on what else is visible on screen at the time. If you've got a browser with a visible address bar and a bottom toolbar, that's less room for the page than a browser that hides both of those while you're scrolling.

CSS media queries respond to viewport size, full stop. Not the resolution printed on a spec sheet or a marketing page. If you're debugging why a breakpoint isn't firing where you expected, the viewport number here is the one to trust, not whatever the phone's product page says its resolution is. I've seen developers set a breakpoint at 768px, test it on a device with a 768px screen resolution, and be confused when the breakpoint doesn't trigger — because the viewport is actually 752px after the browser chrome takes its cut.

Two phones can report the exact same viewport width in CSS terms while having wildly different actual screen resolutions. That's device pixel ratio doing its job — rendering content sharper without changing how much "space" the page thinks it has to work with. A 2x DPR phone renders each CSS pixel as a 2x2 block of physical pixels, making text and images look crisp, but the page still thinks it has the same layout width as a 1x phone. This is also why a screenshot taken on a high-DPR phone often looks much larger in raw pixel dimensions than the CSS layout would suggest. You might think your page is laid out at 375px wide, but the screenshot file is 1170px across. That's not a bug — that's just how DPR works.

Understanding this distinction matters because it affects how you write CSS, how you test responsive layouts, and how you interpret screenshots from users. If someone sends you a screenshot that looks blurry on their phone, it's probably a DPR issue. If elements are overlapping or cut off, it's probably a viewport issue. The Device Dashboard gives you the numbers to tell the difference without guessing.

Some values just aren't available

Certain things — like exact refresh rate, or battery level in some browsers — aren't exposed to web pages by modern browsers. These are privacy and security restrictions, and they're not specific to this site. Browsers intentionally limit what information JavaScript can access about your device and environment, because that same information could theoretically be used for fingerprinting or tracking. When a value isn't available, the tool says so rather than guessing or making up a number that looks plausible but isn't actually measured. A placeholder that tells you "not available" is more useful than a fake number you might make decisions based on.

This is also worth noting because some other tools and browser extensions claim to show information they can't actually access. They either pull from cached data that might be stale, or they infer values from other signals that might be wrong. If a number on this dashboard says it's from a specific API, you can trust it. If the API doesn't provide that value, you'll see that too.

What's under the hood

Everything here comes straight from standard window.screen and navigator APIs. Nothing exotic, no permission prompts, no special access. These are the same APIs any web page can use — the difference is just that this page shows them to you instead of using them quietly in the background for analytics or fingerprinting. That's also why the page loads and updates instantly with no consent dialog interrupting you. There's nothing to consent to. The browser already has this information, and this page is just showing it to you directly.

This approach means the tool works the moment you open it. There's no setup, no configuration, no "please allow access to your device information" prompt that makes you wonder what you're actually agreeing to. It also means the tool can't show you anything the browser doesn't expose, which is why some values are unavailable — but at least you know exactly what you're getting and where it came from.

If you're the kind of person who likes to verify things yourself, you can open your browser's console and type window.screen or navigator.userAgent to see the same raw data this page displays. The dashboard just formats it in a way that's easier to read and keeps it updated as your window changes, so you don't have to keep refreshing the console output manually.

Whether you're debugging a layout issue, verifying a breakpoint, writing up a bug report, or just curious about what your browser is reporting about your device, this gives you the answer in about two seconds. If something looks wrong or confusing, that's worth reporting — it might be a browser quirk worth documenting, or it might be a bug in how the tool reads a particular API.

Browser Feature Detection

Feature detection is checking whether a browser supports a specific API before trying to use it. Instead of sniffing the browser name and guessing what it can do, you ask the browser directly — "do you have this?" — and act on the answer. It's more reliable than user-agent strings, which lie constantly and change with every update.

The ones worth checking most often: WebGL for graphics, LocalStorage for client-side data, Geolocation for location access, and Touch Events for input handling. If you've ever built a slider that works on desktop but breaks on mobile because it assumed mouse events, you already know why this matters.

Progressive enhancement is the broader principle behind this. You build a baseline that works everywhere, then layer on nicer features for browsers that support them. A site doesn't become unusable just because a visitor's browser doesn't support the latest API — it just misses the upgrade. That's a much better failure mode than the page breaking entirely.

Display Capabilities

Some screens can show wider color ranges, HDR, and higher refresh rates than others. If your media takes advantage of that, it looks noticeably better on capable hardware. If it doesn't, it just looks normal — no harm done, but you're leaving quality on the table.

Hardware Performance Insights and Optimization

Browsers don't give you a full picture of what's under the hood, but they do expose enough about CPU, memory, and network to make informed decisions. Knowing whether you're on a low-end or high-end device helps you tune JavaScript, images, animations, and loading strategies accordingly.

Touch Support

Detecting touch lets you build interaction patterns that actually make sense on the device being used. Pointer Events simplify this by unifying mouse, touch, and pen input under one system. Mobile apps also need to handle orientation changes without breaking the layout or losing state.

Core Web Vitals

How fast a page feels depends on device capabilities — LCP, FID, and CLS all shift based on hardware, network, and rendering power. Optimizing assets, trimming JavaScript, and testing across different device classes is the only way to catch real performance problems before users do.

Privacy and Security

Device detection should only exist to make the experience better, not to fingerprint visitors. Modern browsers already limit what APIs can reveal and require explicit permission for sensitive features. The right approach is to collect only what you need, be upfront about it, and don't track anything you don't actually use.