How to color formats and matching rules in the global hex swapper
- Step 1Inspect how your SVG writes colour — Open the file (or use View SVG source after a run) and note the notation. Figma exports typically use hex; some Inkscape/Illustrator exports use
rgb()or named colours. The notation in the file is what you must match. - Step 2Match the from to the literal in the file — If the file uses
#003082, setfromto that hex. If it usesrgb(0,48,130), that exact string is what matches — and the browser picker can't produce it, so you'd need pasted source or the runner. - Step 3Let short-hex equivalence work for you — You don't need to worry about
#fffvs#ffffff: the tool expands 3-digit hex first, so a 6-digitfromcatches the 3-digit spelling too. - Step 4Don't rely on format conversion — Setting
fromto#ff0000will not touchrgb(255,0,0)orred. There is no conversion. Treat each notation as a separate target. - Step 5Normalise mixed-format files first — If one file uses several notations for the same colour, re-export to hex (most editors can) before swapping, so a single hex pair catches every instance.
- Step 6Confirm with the swap count — After processing, the 'Colors swapped' number tells you how many literal matches happened. Zero almost always means a format mismatch between your
fromand the file.
What matches what
The swapper's matching is literal, with two equivalences: short↔full hex and letter case. Everything else is a distinct string.
| from value | Matches in file | Does NOT match |
|---|---|---|
#ffffff | #ffffff, #FFFFFF, #fff, #FFF | rgb(255,255,255), white |
#ff0000 | #ff0000, #FF0000, #f00, #F00 | rgb(255,0,0), hsl(0,100%,50%), red |
rgb(0,48,130) | the literal rgb(0,48,130) (case-insensitive) | #003082, rgb(0, 48, 130) (different spacing) |
red | the literal word red | #ff0000, rgb(255,0,0) |
currentColor | the literal currentcolor (case-insensitive) | any resolved hex it renders as |
Notation by source app, and the catch
Where common editors land on colour notation, and what it means for matching.
| Source | Typical notation | Matching note |
|---|---|---|
| Figma export | 6-digit hex | Matches cleanly with hex from |
| Inkscape | Often #rrggbb, sometimes rgb() in style | Check style= blocks for rgb() |
| Illustrator | Mix of hex and named | Named colours need literal-word from |
| Hand-written SVG | Anything (shorthand, names) | Verify the exact spelling first |
| Browser-picker (this UI) | 6-digit hex only | from/to are always hex in the web tool |
Cookbook
Exact matching behaviour, shown with minimal snippets.
Short and full hex collapse to one match
The document is normalised so 3-digit hex becomes 6-digit before matching. One 6-digit pair catches both spellings.
Before: <rect fill="#f00"/> <rect fill="#FF0000"/> Pair: #ff0000 -> #e3342f After (Colors swapped: 2): <rect fill="#e3342f"/> <rect fill="#e3342f"/>
Hex from does not touch rgb()
The same red in two notations: only the hex instance is swapped. This is the single most common surprise.
Before: <rect fill="#ff0000"/> <rect fill="rgb(255,0,0)"/> Pair: #ff0000 -> #e3342f After (Colors swapped: 1): <rect fill="#e3342f"/> <rect fill="rgb(255,0,0)"/> <- untouched
Named colour matches only as a word
Setting from to a name matches the literal word in the markup, not its hex equivalent.
Before: <rect fill="red"/> <rect fill="#ff0000"/> Pair: red -> #e3342f (set via pasted source) After (Colors swapped: 1): <rect fill="#e3342f"/> <rect fill="#ff0000"/> <- a name pair won't touch hex
Whitespace inside rgb() must match exactly
Because matching is literal, rgb(0,48,130) and rgb(0, 48, 130) are different strings. Spacing matters.
File: fill="rgb(0, 48, 130)" (spaces after commas) Pair from: rgb(0,48,130) (no spaces) Result: Colors swapped: 0 (different string) Fix: copy the literal string from View SVG source including its exact spacing.
Normalise, then one hex pair covers all
When a file mixes notations, convert to hex on export first; afterward a single hex pair catches every instance.
Mixed file: #ff0000, rgb(255,0,0), red Step 1: re-export from your editor as hex -> all three become #ff0000 Step 2: Pair #ff0000 -> #e3342f -> Colors swapped: 3 (everything caught)
Edge cases and what actually happens
Hex from, rgb() in file
No matchThe most common format trap. #ff0000 does not match rgb(255,0,0) — there is no conversion. The swap reports those instances as unchanged. Match the literal notation, or normalise to hex first.
Named colour expected to match hex
Literal onlyfrom: red matches only the literal word red. It will not find #ff0000. There's no name-to-hex table in the matcher. To swap both, run two pairs (one for the name, one for the hex).
HSL colours
No conversionhsl()/hsla() values are matched only as literal strings, exactly as written. A hex from won't touch them, and the formatting (spaces, percent signs) must match exactly. Convert to hex on export for reliable swapping.
rgba() / 8-digit hex with alpha
Literal onlyAlpha-bearing forms (rgba(…), #rrggbbaa) are matched as literal strings too. An opaque hex from won't catch the alpha variant. Note that 3-digit expansion only applies to plain #rgb, not 4-digit #rgba.
Spacing or case differences inside rgb()
MismatchMatching is case-insensitive but otherwise literal. rgb(0,48,130) ≠ rgb(0, 48, 130) because of the spaces. Copy the exact string (including spacing) from the source when using rgb()/hsl() from values.
currentColor in the file
Keyword, not a colourcurrentColor resolves to the CSS color at render time; in the file it's the literal token currentcolor. The swapper can replace that literal string if you target it, but it has no idea what hue it renders as.
Browser picker can't enter non-hex from
UI limitThe web UI uses native colour pickers that only emit 6-digit hex. To set a from of rgb()/hsl()/a name, you'd need the pasted-source path's parsing limits or the runner API — in the standard UI, from and to are always hex.
Swap count is zero
No matchZero swaps means the from string isn't present as written. Nine times out of ten it's a format mismatch (hex from vs rgb file, or spacing differences). Open View SVG source and copy the exact literal.
Frequently asked questions
Does the swapper treat #fff and #ffffff as the same colour?
Yes. Before matching, every 3-digit hex in the document is expanded to 6-digit, and a 6-digit from is expanded the same way. So #fff, #FFF, #ffffff, and #FFFFFF all match one pair.
Can I swap rgb(0,0,255) to #0000ff in one pair?
No. The swapper doesn't convert formats. A from of rgb(0,0,255) matches only that literal string; a from of #0000ff matches only the hex. To change both notations you'd run two pairs. (And the browser picker only produces hex, so an rgb from requires pasted source or the runner.)
Are HSL colours supported?
Only as literal strings. The matcher does not parse or convert hsl()/hsla(). It will replace an hsl(…) value if your from is that exact string (case-insensitive, exact spacing), but a hex from will never match it. For reliable swapping, normalise to hex first.
Does it understand named colours like red or steelblue?
Only as words. from: red matches the literal red in the markup, not #ff0000. There's no CSS-name lookup table in matching. Note: a separate part of the codebase knows a small name table, but it isn't used by the Hex Swapper's matching.
Why did my swap change nothing?
Almost always a format mismatch: your from is hex but the file uses rgb()/hsl()/a name, or your rgb from has different spacing than the file. Open View SVG source, copy the exact literal string, and match it precisely.
Is matching case-sensitive?
No. Matching is case-insensitive, so #FF0000 and #ff0000 are equivalent, and RGB(...) matches rgb(...). Only the literal characters (digits, commas, spacing) otherwise have to line up.
How are rgba() and 8-digit hex with alpha handled?
As literal strings, like everything else. An opaque hex from won't match rgba(...) or #rrggbbaa. Also, the 3-digit expansion applies only to #rgb, not 4-digit #rgba, so those are matched verbatim.
Does currentColor get swapped?
Only if you target the literal token currentColor. It's a CSS keyword, not a fixed colour, so the matcher treats it as a string. It can't know which hue it renders as, and it isn't matched by any hex from.
Can the browser tool accept an rgb() or named source?
Not via the colour pickers — they only emit 6-digit hex. In normal UI use, both from and to are hex. Non-hex literals would come through the pasted-source path or the runner API, where the engine still matches them literally.
What's the cleanest way to handle a mixed-format file?
Re-export it from your editor with hex colours so every instance of a colour is the same string, then run a single hex pair. This avoids juggling multiple from notations for one colour.
Does the spacing in rgb() really matter?
Yes. rgb(0,48,130) and rgb(0, 48, 130) are different literal strings and won't cross-match. Copy the exact text — including spaces — from the source if you must use an rgb from.
Is the format behaviour the same in the API and the web tool?
Yes. The runner-backed API uses the same engine logic — short-hex expansion plus case-insensitive literal replace — so the matching rules in this reference apply identically whether you use the website or script the swap.
Privacy first
Every JAD SVG tool runs entirely in your browser using the DOM API and Canvas. Your SVG files never leave your device — verified by zero outbound network requests during processing.