Build the HDR glow yourself, or use the API?
If you're reading this, you probably already know the trick: a JPEG with an HDR color profile embedded renders its brightest areas above the screen's normal white point on HDR displays. It's the effect behind the glowing logos in the LinkedIn feed. The concept is public, it was first documented by Tom Nick, and yes, you can prompt an AI to write you a working-looking implementation in an hour.
I built Superwhite, so I'm biased, but this page is not going to pretend you can't build it. Instead it's the page I wish existed when I started: an honest map of where do-it-yourself implementations break, because the gap between "renders brighter" and "looks professional in a feed at 4000 nits" is where I've spent most of my time.
The concept, in one paragraph
You re-encode the image with a wide-gamut HDR color profile that uses the PQ transfer function, splice that profile into the JPEG, and rely on the fact that some platforms keep the color profile through their image pipeline while stripping other HDR metadata. On an HDR display, the bright areas of the image then render in the display's extra brightness headroom. The full conceptual walkthrough is in how Superwhite works.
Where naive implementations break
Every one of these is invisible in a quick test and obvious in a real feed. If you're evaluating AI-generated code for this, test against this list.
1. Banding in anything that isn't flat color
The PQ transfer function redistributes an 8-bit image's code values aggressively. Flat logos survive, but any gradient, glow, drop shadow, or photograph develops visible stair-step banding once the peak brightness goes up. Most generated implementations do a straight per-pixel conversion and ship the banding.
2. Noise you couldn't see becomes blotching you can't unsee
Almost every "white" background in a real-world source image is full of low-level JPEG noise from an earlier compression pass. At normal brightness it's invisible. Boosted into HDR headroom, it becomes visible blotching across the background. Clean-looking inputs are not clean, and a pipeline that doesn't account for this produces output that looks dirty on exactly the displays where the effect works.
3. Color smearing at the glow boundary
Standard browser and library JPEG encoding subsamples color information. In normal photos nobody notices. At a hard boundary between a glowing white element and a colored background, the subsampling smears, and the crisp edge that makes a logo look premium turns soft and fringed.
4. The output has to survive recompression
LinkedIn re-encodes what you upload. An implementation that looks right locally can come out the other side with the effect weakened, artifacts amplified, or the profile handled differently depending on the upload path. Cropping or editing in the composer kills it entirely. Getting output that reliably survives the pipeline, and knowing which paths preserve it this month, is ongoing work, not a line of code.
5. Double processing produces grey mush
Run an already-converted image back through the conversion and you get flat, washed-out output. In any real workflow, someone will eventually feed the tool its own output. If your pipeline can't detect that, your users will blame the technique, not their input.
6. Boosting everything looks radioactive
Without per-pixel masking of what should glow and what shouldn't, the whole image lifts, and the result reads as broken rather than premium. This is also where eye-strain complaints come from. Deciding what glows, how much, and how the transition behaves is a design problem sitting on top of the encoding problem.
7. It's a moving target
The whole trick lives on platform behavior that isn't documented or guaranteed. Platforms change their image pipelines without notice. Code an AI generates for you today is frozen; the behavior it depends on is not. Whoever owns the implementation owns the monitoring.
When you should absolutely build it yourself
A one-off internal experiment, a hobby project, learning how HDR and color profiles work: build it, it's a genuinely fun rabbit hole. Start from Tom Nick's writeup, test on a real HDR phone, and check your results against the list above. Nothing here is secret, it's just work.
When the API makes more sense
If the output ships to customers, the calculus changes. A scheduling tool, content platform, or agency putting this in front of paying users needs the artifact handling, the masking behavior, and someone watching when a platform changes its pipeline. That's what Superwhite's licensed pipeline is: the same engine behind the tool, as a hosted API endpoint or a licensed JS module, maintained as platforms move.
Pilot licenses start at €149 per month. Tell me what you're building on the API request form and I will reply within a day.