Save brand colors on Mac with pinned swatches

The short version: use a local Mac color picker to sample the rendered brand colors, rename each useful color by role, pin only the values you expect to reuse, then export the pinned palette as text or JSON. Do this before the review, not while people are waiting.

This is different from keeping every color sample forever. History is for recent work. Pins are for colors you would defend, reuse, or hand to someone else.

teenycolor is built around that line. It samples screen colors, copies your preferred format, keeps local history, lets you rename and pin colors, and exports pinned colors when the palette is ready to share.

Quick answer

01Sample the rendered color, not the memory of it

If the client asks whether a button, badge, or dark-mode surface is using the right color, measure the rendered UI. Design tokens, CSS variables, SwiftUI colors, opacity, vibrancy, antialiasing, and display profiles can all affect what a reviewer sees.

teenycolor uses Apple's NSColorSampler path through its color picker service. Once a color is picked, the app inserts it at the top of local history and copies it to the clipboard in the selected format.

That makes the first capture fast. The rest of the workflow decides whether the sample deserves to stay.

02Name swatches by job, not by mood

Names should answer the review question later. "Blue" is not enough. "Primary button light", "Primary button dark", "Warning text", or "Selected sidebar row" is better because the name carries the UI role.

The TeenyColor source stores an optional name on each picked color. The row menu exposes rename, and exported text keeps the name next to the value. JSON export includes the name when one exists.

Keep names short. If the name needs a sentence, the color probably belongs in a design note, not in the swatch name.

03Pin only review-worthy colors

Pinning is a commitment. It says this color should survive history cleanup and stay visible. Use it for brand values, approved UI states, client-specific colors, and values you need to compare again.

TeenyColor keeps pinned and unpinned colors separate in the popover. Clearing history removes unpinned colors and keeps pinned ones. The app also enforces a cap of 100 pinned colors, which is plenty for real project palettes and a useful guard against turning pins into a junk drawer.

When the saved colors are for a launch page, run the product page color QA checklist after pinning the intended values. It separates the token or CSS value from the rendered pixel, screenshot profile, and contrast pair, then ties each result to the exact build and page state.

For most client reviews, the right number is small: primary, secondary, text, surface, warning, success, selected state, disabled state. If you need more, split by screen or project.

04Let history age out the throwaways

Recent samples are useful during active work. They are less useful two weeks later when you no longer remember why a pixel was sampled. That is where history limits help.

TeenyColor exposes history limits of 20, 50, or 100 unpinned colors. The source trims the oldest unpinned entries and leaves pinned colors alone. That gives you room for exploration without risking the values that need to survive.

Start at 50 if you do UI QA or design handoff often. Use 20 if you mostly sample colors for quick copy-and-paste work. Move to 100 only if you regularly compare many rendered states in one pass.

05Export before the review turns into archaeology

If another person needs the palette, export it before the review. A screenshot plus a verbal "it's the orange one" is weak handoff. A named list of values is better.

TeenyColor can export pinned colors only or all colors. Text export uses the currently selected format and writes names as Name: value. JSON export includes hex, RGB, HSL, and optional name for each color.

Use text for a quick Slack or ticket paste. Use JSON when the recipient may script, diff, or store the palette. If someone needs contrast checks or tints and shades next, link the color values into the relevant TeenyApps tools instead of resampling.

Where Apple's Digital Color Meter fits

Digital Color Meter is still useful for a one-off measurement, especially when you want a built-in Apple utility. Apple's user guide covers measuring on-screen colors and copying values.

For repeat client work, the gap is persistence. Apple's guide does not describe pinned swatches, named palette history, or text/JSON export. If the task is "tell me this pixel value once", the built-in tool can be enough. If the task is "keep these brand colors ready for the next review", use a palette workflow.

Five-minute brand color pass

1. Open the real UI state you plan to review.
2. Sample the important brand and state colors locally.
3. Rename each keeper by role and mode.
4. Pin the values that should survive history cleanup.
5. Delete or ignore one-off samples that do not matter.
6. Export pinned colors before sharing the review notes.

Sources checked

• TeenyColor homepage and TeenyColor Swift source for screen sampling, clipboard copying, selected format, local history, names, pins, history limits, max pinned items, text export, and JSON export.
• Apple Developer Documentation: NSColorSampler.
• Apple Support: Digital Color Meter User Guide for Mac.
• TeenyApps: Mac app demo checklist for client reviews.

FAQ

How do I save brand colors on Mac?

Sample the rendered colors locally, name them by role, pin the colors that matter, and export the pinned palette before review or handoff.

Should every sampled color be pinned?

No. Pin colors you expect to reuse or defend. Leave one-off samples in history so they can age out.

Can Digital Color Meter save a brand palette?

Digital Color Meter is useful for one-off measurement, but Apple's user guide does not present it as a pinned palette or export workflow.