You have a client, a domain and no brand guide. Here is how to get a working brand kit from the live site, and what to verify before you trust it.
Step 1: see what is there
Paste the domain into the tool on the home page. In a few seconds you get the logo, the palette with a role for each color, the fonts, and the page title and description. Click a swatch to copy its hex value.
This is the fast, no-account way to see what a site is really using.
Step 2: get the structured version
For anything repeatable, use the API or an SDK. Brand extraction returns the same data as JSON. The styleguide call adds CSS tokens and the type scale, which is what you want if you are rebuilding the site or generating components.
Step 3: grab references
Screenshots at desktop, tablet and phone widths give you visual references. Pair them with the page text from the Markdown scrape and you have a handoff packet. More on that flow in design handoff.
What to check by hand
Automatic extraction reads what the site serves. That is usually right and sometimes not what the client considers the brand. Check these:
- The logo. Is it the primary mark, or a partner badge in the header?
- Roles. The “accent” color might be a promo banner color for this month.
- Fonts. A site can load a font for one section only. Confirm which is body and which is heading.
- Dark mode. If the brand has a dark variant, the live site may not show it.
Treat the output as a strong first draft that saves the hour of digging, then spend five minutes confirming it.
Make it routine
If you do this for every new client, put it in a script and run it at intake. The Free plan covers 100 pages a month to try it, and brand calls use weighted credits, as the pricing page explains.
A worked example
Say the client is a regional landscaping company and all you have is their domain. You paste it into the tool and see a green logo, a palette of five colors, and two fonts. The primary green and a dark gray for text are obvious. The palette also holds a bright orange. Is that the brand accent, or the color of a seasonal banner? You open the live site and find that the orange is the call-to-action button. That is a real accent, so it stays. You also notice that the logo in the header is a horizontal version, while the footer shows a stacked version. You ask the client which one is the primary mark.
That whole check takes about five minutes, and you have a brand kit you can defend. Compare that with the usual alternative, which is an email asking the client to send brand files, followed by a week of waiting and a PDF with a logo at 72 pixels.
Turning the data into a starting point
Once you trust the palette, put it somewhere useful. Write the colors as design tokens in your stylesheet or design tool, with names that reflect their role, not their hue. A token called primary survives a redesign. A token called green does not. Record the font families and note which ones you can license or load from a public source. If the site uses a font you cannot get, pick a close match and write down why.
Then check contrast before you build on top of it. Brand colors are chosen for logos, not for body text. Test the text color against the background and the button label against the button fill. If a color fails, keep it for large elements and pick a safer shade for small text. This is a design decision, not a tooling problem, and it is worth making once, early.
What this approach is not
It is not a replacement for a real brand guide. A guide explains spacing, voice, how the logo may be used and what is off limits. Extraction reads what a website happens to serve today. If a client has a guide, use it and treat the extracted data as a cross-check. If they do not, the extracted kit is a sensible place to start and a good prompt for the conversation about what they actually want.
It also reads public pages only. If the real brand lives in a private style library or an internal tool, you will not see it from outside. And you should only run it on sites where this kind of reading is acceptable, which the acceptable use policy covers.
When to automate
If you do this once a month, the tool on the home page is enough. If you do it for every lead or every new project, call the API at intake and store the result with the record. You pay for the call once and read it from your own database afterwards. That is the pattern I use for my own client work, and it is the reason the product exists.