Why Swift represents color as floats, not bytes
UIColor, part of Apple's UIKit framework (and closely mirrored by SwiftUI's Color type), stores each RGB channel as a floating-point number between 0.0 and 1.0 rather than an integer between 0 and 255. That's a deliberate design choice consistent with how Apple's graphics frameworks handle color throughout — Core Graphics and Core Animation both work in normalized 0–1 color space internally, in part because it generalizes cleanly to color spaces and bit depths beyond standard 8-bit-per-channel RGB, and blends and interpolates predictably in calculations without needing to rescale between integer ranges first.
Converting hex bytes to normalized floats
The conversion itself is simple division: each hex byte pair converts to an integer 0–255 exactly as it would for RGB, then that integer is divided by 255 to land in the 0.0–1.0 range Swift expects. For#3B82F6: red byte 3B is 59, giving 59 ⁄ 255 ≈ 0.231; green byte82 is 130, giving 130 ⁄ 255 ≈ 0.510; blue byte F6 is 246, giving 246 ⁄ 255 ≈ 0.965. The result, formatted the way it would appear in Swift source code, isUIColor(red: 0.231, green: 0.510, blue: 0.965, alpha: 1.000). This tool rounds to three decimal places, which is more than enough precision to round-trip back to the exact original byte value in practice.
Why this tool doesn't handle alpha beyond 1.0
UIColor's initializer does accept an alpha parameter, and this tool always fills it in as1.000 (fully opaque), since the hex side of this converter is a plain 6-digit color with no transparency information to carry over. If a UIColor value needs a specific alpha less than 1.0, the alpha argument can be edited directly in the generated snippet, or theHex ↔ RGBA tool can be used to work out the correct alpha value from an 8-digit hex color first.
Beyond RGB: UIColor's other color spaces
This tool covers UIColor's most common initializer — red:green:blue:alpha: — but UIColor supports several other ways to construct a color, including HSB (hue, saturation, brightness, matching the HSV model discussed elsewhere on this site), grayscale with a single white value plus alpha, and named system colors (UIColor.systemBlue, UIColor.label, and similar) that automatically adapt their actual RGB values for light mode, dark mode, and accessibility settings. Converting a specific hex value to a fixed RGB-based UIColor, as this tool does, is appropriate for a literal brand or design color; it deliberately doesn't attempt to match against Apple's dynamic system colors, since those aren't fixed hex values at all — their underlying color changes automatically based on the user's system appearance settings.
Where this conversion is actually needed
Designers frequently hand off colors as hex codes (from Figma, Sketch, or a brand style guide), while iOS and macOS developers need those same colors expressed as UIColor or SwiftUI Color initializers directly in source code. Doing that conversion by hand — dividing three separate byte values by 255 and rounding — is tedious and error-prone to do repeatedly across a design system's full color palette, which is the practical gap this tool fills: pasting in a hex value from a design file and getting back ready-to-paste Swift code, rather than manually working out each normalized channel value.
SwiftUI's Color versus UIKit's UIColor
SwiftUI's native Color type uses a very similar initializer —Color(red: 0.231, green: 0.510, blue: 0.965) — with the same 0–1 normalized channels and the same underlying conversion math, so the values generated here apply equally to either API; only the surrounding initializer syntax differs between UIKit and SwiftUI.
One difference worth knowing: SwiftUI's Color often needs an explicitColor(uiColor:) or asset-catalog-based bridge to interoperate cleanly with existing UIColor-based code in a mixed UIKit/SwiftUI codebase, since the two types aren't always drop-in replacements for each other despite sharing near-identical initializer signatures for plain RGB values.