How I Built Color Scheme Extractor

I built Color Scheme Extractor because I kept running into the same small design problem.

I would land on a website that looked good, pause for a second, and think:

"Why does this color system feel so clean?"

Sometimes it was a SaaS landing page with one confident accent color. Sometimes it was a portfolio with soft neutrals and sharp text. Sometimes it was a product dashboard where the borders, cards, and text colors were doing more work than the primary brand color.

I did what most builders do at first. I opened DevTools, clicked around, inspected elements, copied a few hex values, and tried to reconstruct the palette manually.

It worked, but it felt clumsy.

The color I clicked was not always the color that mattered. A page might have dozens of colors from icons, shadows, gradients, images, borders, hover states, and third-party widgets. Some were important. Some were noise. Some appeared only once. Some appeared everywhere but were easy to ignore because they were subtle.

I did not want a basic color picker.

I wanted a tool that could look at a page and help me understand the color system behind it.

That became Color Scheme Extractor.

The first version was simple in my head: scan the page, collect colors, show the palette.

The real version was more interesting.

The problem was not finding colors

The first surprise was that extracting colors is easy.

Understanding them is harder.

A webpage has colors everywhere:

• text
• backgrounds
• borders
• buttons
• links
• SVG icons
• shadows
• gradients
• outlines
• pseudo-elements
• disabled states
• badges
• cards
• image overlays

If you only collect every color and dump it into a list, the result is not very useful. You get a pile of swatches, but not much meaning.

The useful question is not:

Which colors exist on this page?

The useful question is:

Which colors define this page?

That one change shaped the extension.

I needed to think less like a scraper and more like a designer studying a page.

A color used on 1,000 text elements matters differently from a color used on one small decorative icon. A background color covering the whole page matters differently from a border color used on cards. A bright accent might appear rarely but still define the brand because it controls the main CTA.

So the extension could not stop at detection. It needed grouping, frequency, semantic roles, and enough context to help a human make sense of the palette.

The first scan was too noisy

My earliest version collected computed styles from elements and looked for color values.

Something like this, conceptually:

const styles = getComputedStyle(element)
 
const colors = [
  styles.color,
  styles.backgroundColor,
  styles.borderColor,
]

That gave me colors quickly.

It also gave me too much noise.

Transparent colors showed up. Repeated values showed up. Similar whites and grays showed up separately. Border colors with almost no visual importance appeared beside major brand colors. Some elements inherited colors. Some backgrounds were transparent but visually sat on top of a parent surface.

The first output looked technically correct and practically confusing.

That is a common product trap: the data is true, but the experience is not useful yet.

So I started filtering.

I ignored transparent values. I normalized color formats. I counted frequency. I looked at whether a color came from text, background, border, or another role. I started thinking about whether a color should be shown as a primary swatch, a supporting neutral, or a minor detail.

That moved the tool closer to what I wanted.

Not perfect. But more useful.

I had to decide what counts as a color system

This was the real design decision.

If a website has 100 colors, does it have a 100-color palette?

Usually no.

Most pages have a smaller system hiding inside the noise. Maybe five to twelve colors do the majority of the work:

• main background
• surface background
• primary text
• muted text
• primary action
• accent
• border
• success
• warning
• error

The challenge was helping the user see that system.

That is why Color Scheme Extractor shows more than a list. It tries to surface roles and tokens. The goal is to help someone look at a page and say:

"Okay, this is the primary color. This is the background. This is the heading color. This is the accent. This gray is doing most of the border work."

That sounds simple, but it changes the usefulness of the tool.

A palette without roles is just decoration.

A palette with roles becomes something you can use.

Design tokens became the bridge

Once I started thinking in roles, design tokens became the obvious next step.

A designer or builder does not only need #635BFF.

They need to know whether that color should become:

--primary: #635BFF;

or:

--accent: #635BFF;

or maybe:

--link: #635BFF;

The name matters because the name tells the color what job it has.

This is why the extension includes token-style output. It helps turn inspiration into a usable system. Instead of copying random values into a project, you can translate them into roles:

:root {
  --background: #ffffff;
  --foreground: #1a1f36;
  --primary: #635bff;
  --accent: #00d4ff;
  --border: #e6ebf1;
  --muted: #f6f9fc;
}

That was one of the moments where the extension started feeling more like a product and less like a utility.

It was not only answering "what color is this?"

It was helping answer "how could I use this?"

Accessibility changed the product

At first, I thought accessibility would be a later feature.

Extract colors first. Add contrast checks later.

But the more I used the extension, the more obvious it became that color extraction without contrast is incomplete.

A palette can look beautiful and still be hard to read.

A muted text color can look elegant in a screenshot and fail on a real page. A bright accent can look exciting until you put white text on top of it. A soft background can feel premium until the labels disappear.

So accessibility moved closer to the center of the product.

I added contrast analysis because I wanted the tool to do more than inspire. I wanted it to protect the user from bad decisions.

This is especially important for landing pages.

A landing page is not just a visual mood board. It has to communicate. People need to read the headline, understand the paragraph, find the CTA, scan feature cards, and trust the product.

If the contrast is weak, the page loses clarity.

The accessibility tab was my way of saying: do not just collect nice colors. Check whether they work together.

That one feature made the extension feel more responsible.

The popup UI had to stay compact

Chrome extension popups have a strange constraint: they need to feel useful in a small space.

A web dashboard can spread out. A popup cannot.

That forced me to make decisions.

What should the user see first?

How many colors are enough before the popup feels crowded?

Should the tool show frequency first, brightness first, or semantic role first?

Should export be a main feature or a supporting tab?

How do I show contrast results without making the popup feel like a spreadsheet?

Small products make these decisions unavoidable. You cannot hide complexity behind a giant layout.

For Color Scheme Extractor, I leaned into tabs:

• colors
• tokens
• accessibility
• export
• history
• settings

That structure gave each job its own place. The colors tab is for immediate understanding. The tokens tab is for builders. The accessibility tab is for contrast. Export is for taking the result elsewhere.

The product became easier to explain once the UI matched the user’s workflow.

First see the palette.

Then understand the roles.

Then check contrast.

Then export if useful.

Export mattered more than I expected

At first, exporting felt like a nice-to-have.

Then I realized it is part of the workflow.

If someone extracts a palette and likes it, the next natural step is using it somewhere else. That might be CSS variables, JSON, Tailwind config, a design note, or a quick reference while building.

A color tool that stops at display forces the user to do manual work.

Export turns the result into momentum.

That matters for solo builders because momentum is fragile. When you are building alone, small interruptions stack up. If a tool gives you a useful palette but then makes you rewrite everything manually, you lose the spark.

The export feature helps the extension feel like part of the build process, not just a viewing tool.

I learned that small tools still need product thinking

Color Scheme Extractor is a small product.

That does not mean it is simple.

Small tools still need positioning. They still need a clear user. They still need UI decisions, edge case handling, error states, copy, screenshots, privacy boundaries, and a reason to exist.

The mistake I used to make was thinking a small utility could skip product thinking.

It cannot.

If anything, small utilities need sharper product thinking because they have less room to explain themselves.

The user should understand quickly:

• what the tool does
• when to use it
• what output they get
• how to apply that output
• why it is better than manually clicking around

That clarity became part of the build.

The extension is not "a thing that gets colors."

It is a way to extract a website color system and turn it into design tokens, contrast checks, and usable references.

That sentence took longer to discover than the first code did.

The hardest part was deciding what not to include

Once the extension started working, the feature ideas multiplied.

I could add AI palette naming.

I could add automatic brand mood detection.

I could add screenshot annotation.

I could add Figma export.

I could add theme generation.

I could add color blindness simulation.

I could add project folders.

Some of those ideas are good. Some may happen later.

But the first published version needed focus.

The core promise was enough:

Extract a website color system, understand the roles, check contrast, and export the palette.

That is already useful.

Adding too much too soon would make the tool harder to explain and slower to finish.

This is one of the lessons I keep relearning as a solo developer: a finished small product teaches more than an unfinished large one.

Publishing made the tool feel real

Before publishing, Color Scheme Extractor was just something I was building.

After publishing it on the Chrome Web Store, it became something I had to explain to strangers.

That changed the way I looked at the extension.

The screenshots had to show the product clearly. The description had to explain the use case. The permissions had to make sense. The privacy story had to be calm and specific. The first screen had to communicate value fast.

Publishing is a strange kind of design review.

It forces you to see the product from the outside.

Would someone understand this from the listing?

Would a designer know why it helps?

Would a developer know what to export?

Would a solo founder see how it helps with landing pages?

Those questions improved the product more than another private refactor would have.

What I would improve next

The nice thing about a small extension is that the next steps are clear.

I want the product to get better at explaining why a color was assigned a role. If a color is labeled as primary, the user should understand the signal behind that guess.

I want export formats to become more useful for real workflows: CSS variables, Tailwind-friendly tokens, JSON, and maybe design-system notes.

I want the history feature to become more helpful for comparing websites, because studying palettes over time is valuable.

I also want the accessibility side to become more educational. Contrast numbers are useful, but users also need plain-English guidance:

• this works for body text
• this only works for large text
• this is better as a background color
• this accent needs darker text

That kind of guidance is where the product can become more than a detector.

It can become a teacher.

What this project taught me

Building Color Scheme Extractor reminded me that useful products often start from a small repeated annoyance.

I did not begin with a huge platform idea.

I began with a moment:

"I like this website’s colors, but I do not want to manually inspect everything."

That was enough.

The deeper I went, the more the problem opened up. Color extraction led to roles. Roles led to tokens. Tokens led to export. Export led to real workflows. Real workflows led to contrast and accessibility.

That is how small products grow in a healthy way.

Not by adding random features, but by following the user’s next question.

The user asks:

"What colors are on this page?"

Then:

"Which ones matter?"

Then:

"What role do they play?"

Then:

"Can I use them?"

Then:

"Will people be able to read them?"

Then:

"How do I bring this into my project?"

That chain became the product.

My advice if you want to build a small extension

Start with one repeated pain that you actually feel.

Do not start with the largest possible version.

Build the narrow thing that helps you today. Then use it enough to notice where it fails. The failures will tell you what the product really needs.

For Color Scheme Extractor, the first failure was noise. Then missing roles. Then missing contrast. Then missing export. Each limitation pointed toward a better version.

That is a much better guide than guessing features in a vacuum.

Also, keep the user’s next action in mind.

If your extension shows information, ask what the user wants to do with that information.

If it analyzes something, ask how the user decides what the analysis means.

If it saves time, make sure it does not create new manual work immediately afterward.

A good tool does not only produce output.

It moves the user forward.

That is what I wanted Color Scheme Extractor to do.

Not just show colors.

Help someone understand a website’s visual system, learn from it, and build with more confidence.