The problem
Designers and developers often need to know how an existing site is built: which font, which colour, which spacing. It might be a competitor's page, a client's old site or a reference for a new build.
DevTools gives the answer, but not quickly and not in a designer-friendly form. You hunt through the elements panel, read computed styles line by line, and translate CSS values back into the language of a design file. For someone who works in a design tool all day, that is a lot of friction for one font name or one spacing value.
The gap was a way to point at something on a page and simply read its design details, without learning where DevTools keeps them.
The need is sharper when time is tight. A quick look at how a reference site handles its headings should take seconds, not a detour through panels built for debugging.
What we built
PixLens lets you point at a page element and read its design details in one place.
- Fonts, colours and spacing of any element
- Component-level inspection, so you can look at a button or card as a unit instead of a pile of rules
- No DevTools required, which keeps it usable for people who do not live in code
Behind the simple pointing action is DOM inspection: the extension reads the element you select and the styles applied to it, then presents them in a form a designer can use. The main design decision was what to leave out. Raw CSS has hundreds of properties, and showing all of them recreates the DevTools problem, so the view is organised around what people usually need when gathering a reference.
It is built on Manifest V3 with Chrome APIs and JavaScript, and we handled the listing, privacy policy and store submission as part of the build. For a similar tool, see our Chrome extension development service.
We kept the audience in mind throughout: a designer, a founder or a marketer should be able to use it without knowing CSS. That shaped what is shown first and how it is worded, and it is a useful test for any tool you want non-developers to adopt.
The result
PixLens is live on the Chrome Web Store and speeds up reference-gathering during builds. Instead of switching between a browser, DevTools and a notes file, the person doing the research reads the details directly from the element.
Like our other extensions, it is a Medkon product that we scoped, built and published ourselves.
It is a good example of an extension that removes a small, repeated annoyance. Many internal tools for agencies and product teams start the same way, with one task people do every day and a clumsy way of doing it.
Frequently asked questions
How do you build and publish a Chrome extension?
We scope the single job the extension should do, build it on Manifest V3 with the Chrome APIs it needs, test it across the browsers your users run, then prepare the store listing, screenshots and privacy policy and submit it. We handle the submission for you.
Why do extensions ask for permissions?
Chrome only lets an extension touch pages or features it has declared permission for. A good extension asks for the minimum it needs and explains why. We keep permissions narrow and say what they are for in the listing.
How long does Chrome Web Store review take?
It varies, and it is controlled by Google rather than by us. Clear permissions, an honest description and a privacy policy help it go smoothly. We handle the submission and any follow-up questions from the reviewers.
How much does a custom Chrome extension cost?
Pricing is project-based. A fixed quote follows a free discovery call, once we know what the extension needs to do. A fix or plugin-sized job is usually 1-2 weeks, and a full store, app or platform is 4-8 weeks.