Color Name Finder API

About the Color Name Finder API

A color name API that turns any hex code into the nearest CSS/HTML named color. Send FF5733 and get back Tomato, along with its hex code, its RGB values and a flag saying whether your input was an exact match. It is the quick way to put a human-readable label on a color a user picked, a pixel you sampled, or a value pulled from a stylesheet.

Typical uses are color pickers that show a name next to the swatch, product catalogs that need a searchable color word, design-token tooling, and accessibility features that read a color aloud instead of a hex string.

The Free plan returns the single closest named color and the exact-match flag. Paid plans add the color distance and a similarity percentage for the match, and let you ask for a ranked list of up to 20 closest matches, which is useful when the nearest name is a poor fit and you want to offer alternatives.

How it works

Color Name Finder compares the input against a fixed list of 141 CSS named colors, the number reported in total_named_colors. The hex parameter accepts 3-, 6- or 8-digit hex with or without #; shorthand is expanded and an 8-digit value's alpha pair is ignored. The parsed channels come back as input_rgb.

For each named color the API computes the straight-line Euclidean distance between the two colors in RGB space, the square root of the summed squared channel differences. distance is that value rounded to two decimals, from 0 for an identical color up to about 441.67 for black against white. similarity rescales it to a percentage: 100 minus distance as a share of 441.67, also rounded to two decimals. The list is then sorted by distance, nearest first. exact_match is true only when the nearest distance is exactly 0.

closest_color is the top entry, with name, hex (six digits, no #) and rgb. closest_matches holds the top N entries, where N is the closest parameter, from 1 to 20 with a default of 1. The CSS list contains duplicate values, such as Aqua and Cyan or Fuchsia and Magenta, so two entries can tie at the same distance and appear side by side.

RGB distance is simple and predictable but does not model human perception evenly, so two colors that look close can sit further apart than two that look different. On the Free plan the closest parameter is ignored, and distance, similarity and the closest_matches array are removed.

What people use it for

Design Tools

Identify and name colors in design applications and color pickers

Accessibility

Convert hex colors to named colors for better communication and documentation

Web Development

Find CSS color names for hex values to improve code readability

Color Analysis

Analyze and categorize colors in images and designs with standard color names

Ways to call it

One endpoint, many ways in — REST with JSON, XML, YAML and CSV, plus GraphQL and an MCP interface for AI agents.

JSON

Default REST response

XML

Markup format

YAML

Human-readable

CSV

Tabular export

Beta

GraphQL

Query language

New

MCP

For AI agents

Request parameters — GET /v1/colornamefinder

Sent in the query string. Premium parameters are accepted on every plan but only take effect on plans that include them. Anything not listed here is dropped rather than passed through.

Required

Optional

1
2

curl "https://api.apiverve.com/v1/colornamefinder?hex=FF5733&closest=3" \
  -H "x-api-key: YOUR_API_KEY"

Authentication

Send your key in the x-api-key header. That is the only auth step — no token exchange, and no per-endpoint scope to configure.

Response — GET /v1/colornamefinder

Every APIVerve endpoint returns the same three top-level keys, so one response handler covers your whole integration: status, error and data. Only data changes shape.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

{
  "status": "ok",
  "error": null,
  "data": {
    "input_hex": "#FF5733",
    "input_rgb": {
      "r": 255,
      "g": 87,
      "b": 51
    },
    "exact_match": false,
    "closest_color": {
      "name": "Tomato",
      "hex": "FF6347",
      "distance": 23.32,
      "similarity": 94.72,
      "rgb": {
        "r": 255,
        "g": 99,
        "b": 71
      }
    },
    "closest_matches": [
      {
        "name": "Tomato",
        "hex": "FF6347",
        "distance": 23.32,
        "similarity": 94.72,
        "rgb": {
          "r": 255,
          "g": 99,
          "b": 71
        }
      },
      {
        "name": "Coral",
        "hex": "FF7F50",
        "distance": 49.41,
        "similarity": 88.81,
        "rgb": {
          "r": 255,
          "g": 127,
          "b": 80
        }
      },
      {
        "name": "Chocolate",
        "hex": "D2691E",
        "distance": 52.82,
        "similarity": 88.04,
        "rgb": {
          "r": 210,
          "g": 105,
          "b": 30
        }
      }
    ],
    "total_named_colors": 141
  }
}

Response fields

Paths are relative to data. Premium fields are absent rather than zeroed on plans that do not include them, so check for presence instead of comparing to 0.

Response headers

Every response carries your balance, so your own code always knows where it stands without polling anything. All four are exposed to browsers through CORS.

Errors

Read the HTTP status first, then error for the specific reason. The body names the parameter that has to change.

What a call costs — 1 credits per call

Credits are shared across every APIVerve API — one balance, one key, one bill. Failed requests never count against it, so a rejected input costs nothing.

Calls are what the credits buy at this API's rate — spend them here, on any of the other APIs, or across both. Nothing is reserved per endpoint.

Zero-code embed — one snippet, no backend

Drop an interactive Color Name Finder form onto any page. The widget calls the API for you, so no key ever appears in your markup and there is nothing to deploy.

Changelog — Color Name Finder API

Every change to this endpoint, newest first. Breaking changes ship as a new version and the previous one keeps serving — response fields are added, never removed or retyped in place, so an integration written against v1 keeps working.

Currently v1