
OpenAI
OpenAI · 2026
OpenAI is the most recognized AI company in the world, and their website is a masterclass in communicating complex technology simply. Massive whitespace, restrained typography, confident minimalism — the design says “we don’t need to try hard” in a way that only a market leader can pull off. But beneath that simplicity lies one of the most technically challenging sites in our portfolio: heavy client-side rendering means the page is essentially a blank shell without JavaScript execution.




Simplicity at Scale
OpenAI’s design philosophy is extreme simplicity — and the extremity is the point. The homepage deploys more whitespace per viewport than any other site in our portfolio. Text is set in a single sans-serif family at generous sizes, with tracking and leading tuned for maximum legibility and minimum visual noise. There are no gradients, no illustrations, no decorative elements competing for attention. The design is a statement of confidence: when you’re the company that built ChatGPT, you don’t need visual fireworks to get people’s attention.
The color strategy reinforces this restraint. OpenAI green (#10A37F) appears only in interactive elements — buttons, links, hover states — creating a clear visual hierarchy where color equals action. Everything else lives in grayscale. The result is a site that feels more like a well-typeset document than a marketing page, which is precisely the tone OpenAI wants: serious, considered, trustworthy.
What makes this design genuinely difficult to replicate is that simplicity at this level leaves no room for error. Every pixel of spacing is load-bearing. A heading that’s 2px too large, a margin that’s 4px too tight, a font-weight that’s one step too heavy — any of these breaks the illusion of effortlessness. The site’s visual authority comes entirely from proportion and restraint, which means our static capture had to preserve those proportions with absolute precision.




Client-Side Rendering Challenge
OpenAI’s site is built on Next.js with full React hydration — the initial HTML payload is a 5KB shell containing a root div and a bundle of JavaScript. Without JS execution, the page renders blank. This made it the hardest site in our portfolio to capture with our standard pipeline, which relies on parsing the rendered DOM for asset URLs.
Our initial capture returned essentially nothing — the 5KB HTML shell with no content, no images, no meaningful DOM structure. The Playwright browser was loading the page, but the React components hadn’t mounted by the time we captured the DOM. We adapted our strategy with extended wait times, waiting for specific CSS selectors to appear in the DOM before triggering capture — essentially telling our pipeline “don’t snapshot until you see the hero section rendered.”
This SPA-specific capture logic became a template for handling other JavaScript-heavy sites. The key insight was that modern React sites don’t just need time to load — they need time to hydrate, and hydration timing varies wildly depending on bundle size, code splitting strategy, and whether the site uses streaming server-side rendering or full client-side rendering. OpenAI uses the latter, which means every component mounts client-side after the initial JS bundle executes. Our selector-based wait strategy solved this, but it required site-specific knowledge of what “fully rendered” looks like for each target.




Tackled the most JS-dependent site in our portfolio with extended Playwright wait times and selector-based capture strategies, preserving OpenAI’s distinctive design confidence — the extreme whitespace, the precise typography, the visual restraint that communicates authority through omission.
