Dark Mode: UK Website Design From CSS to 4.5:1 Contrast

Dark mode website design uses light text on dark backgrounds instead of the traditional dark-on-light layout, and it works best when it genuinely improves visual emphasis, suits a bold brand tone, or reduces eye strain for content-heavy sites. The one rule that matters more than any other: offer it when it adds real value, but treat accessibility as non-negotiable. A striking dark theme that fails contrast checks helps nobody.

TL;DR:

• Use gray backgrounds with off white text, and test pairings against WCAG thresholds: 4.5:1 for normal text and 3:1 for large text or interface components.
• Set the browser color scheme at the page root, respect system preferences, and apply saved choices before styles load to prevent a wrong color flash.
• Use dedicated dark variants for logos and complex illustrations, but load separate theme images conditionally; otherwise, light and dark assets can double the image payload.
• Keep articles and documentation light for sustained reading, and limit dark styling to selected features if a full site change could weaken brand recognition.

Table of Contents

• What dark mode means for web design
• Practical design rules for dark themes
• Inspiration: curated examples and what they do well
• How to implement dark mode correctly (CSS and JS essentials)
• Accessibility and WCAG considerations for dark mode
• Testing checklist and cross-browser pitfalls
• Kukoo’s practical checklist: how we design dark-mode sites for clients
• Impact of dark mode on brand identity and visual consistency
• Performance considerations when implementing dark mode
• When not to use dark mode (brief editorial perspective)
• How Kukoo can help deliver an accessible dark-mode website
• FAQ
• Sources

What dark mode means for web design

Dark mode isn’t a single look. It spans from near-black backgrounds to softer mid-grey surfaces, and the choice between them changes how a site feels and how well it performs for real users.

Pure black (#000000) against pure white text looks dramatic in a mockup, but it’s rarely the right production choice. The contrast is so extreme that text can appear to vibrate or “halo” on OLED screens, which tires the eyes faster than a well-judged grey. Most mature dark themes sit closer to deep charcoal, somewhere around #121212 to #1E1E1E, paired with off-white rather than stark white text. This softer pairing still clears accessibility thresholds while feeling calmer to read for long stretches.

Dark mode tends to earn its place in a few recurring situations:

• Visual or media-heavy sites: photography, video and illustration portfolios often look richer against a dark canvas because the content, not the chrome, draws the eye.
• Interfaces used for long sessions: dashboards, code editors and reading apps benefit because a dark theme reduces glare during extended use.
• Brands with a bold or technical identity: fintech, gaming, and creative-tech brands frequently use dark themes to signal sophistication or precision.
• Low-light usage patterns: if analytics show a meaningful share of visits happening in the evening, a dark option reduces strain for that audience.

None of these cases mean dark should replace light outright. The safest default, and the one we recommend to every client weighing this decision, is to detect the visitor’s system preference first and then let them override it manually. That respects the choice someone has already made at the operating-system level, whether that’s for comfort, battery life or personal taste, while still giving them control on your site specifically.

Practical design rules for dark themes

Getting the mechanics of a dark theme right is less about creativity and more about discipline. A handful of rules, applied consistently, separate a dark theme that reads beautifully from one that quietly frustrates visitors.

Contrast comes first. Aim to meet WCAG 2.2 AA thresholds of 4.5:1 for normal text and 3:1 for large text or interface components, and resist the temptation to pair pure white text with a pure black background. That combination technically passes contrast maths but creates visual fatigue over time. A better pairing is off-white text, something like #E0E0E0, set against a deep grey background. It’s gentler on the eye and still comfortably clears accessibility requirements.

Colour needs restraint everywhere except where you want attention. Saturated brand colours that look vivid on a white background can become harsh or glow unpleasantly on dark surfaces. Reserve your brightest or most saturated hues for calls to action, links and status indicators, and desaturate everything else slightly so the palette feels cohesive rather than neon.

Typography needs small adjustments too. Thin font weights that look elegant on light backgrounds often appear to thin out further against dark surfaces, sometimes to the point of illegibility. Nudging body text up to a medium weight and adding a touch more line height keeps paragraphs readable without redesigning your type system from scratch.

Depth and boundaries need rethinking as well, since the shadows that create hierarchy on a light background mostly disappear on dark ones. Instead:

• Use soft, low-opacity glows rather than hard drop shadows to suggest elevation.
• Apply subtle 1px borders in a slightly lighter grey to separate cards and panels.
• Keep shadow blur wide and opacity low, so elevation reads as a gentle lift rather than a hard edge.

Images and illustrations are often the last thing teams think about, and the first thing that looks wrong once dark mode ships. A logo designed for a white background can disappear or look muddy against charcoal. Simple CSS inversion (filter: invert(1)) works for basic line icons, but it distorts photography and multi-colour illustrations badly. For anything more complex than a monochrome icon set, prepare a dedicated dark-mode variant of the asset rather than relying on an automated filter. We cover the groundwork for this kind of visual consistency in our guide to enhancing user experience through visual design, which applies just as much to dark themes as light ones.

Pro Tip: Build your dark palette from your existing brand colours by desaturating them 10 to 15% and lightening dark neutrals slightly, rather than inventing a separate colour system from scratch.

Inspiration: curated examples and what they do well

Looking at live dark-mode sites is more useful than studying mockups, because production sites have already dealt with real content, real contrast edge cases and real browser quirks. A handful of patterns come up again and again across well-executed dark themes.

1. Developer tool and SaaS dashboards often nail contrast discipline: body text sits on deep grey rather than black, and a single bright accent colour marks every interactive element, so your eye never has to guess what’s clickable.
2. Gaming and entertainment sites tend to lead with imagery against the dark canvas, letting screenshots, trailers and artwork provide the colour while the UI chrome stays deliberately muted.
3. Portfolio and agency sites frequently use dark mode to put the work front and centre: a photographer’s images or a studio’s case studies look more gallery-like against a dark background than a bright white one.
4. Editorial and publishing platforms that offer dark mode usually keep it optional and tuned for long reading sessions, with generous line height and a warmer, less contrasty grey than a typical app interface.

The pattern worth adapting, not copying, is the relationship between content type and contrast level. A product site selling physical goods needs enough contrast and neutrality that colours and photography stay true to life, so a near-black background with careful colour management suits it better than a warm charcoal. A portfolio can afford more atmosphere and mood lighting in its palette because the goal is impression, not product accuracy. An editorial site should prioritise long-session comfort over drama, which usually means softer contrast than you’d expect.

What’s worth avoiding is lifting an entire visual system wholesale from a site in a different category. A fintech dashboard’s ultra-high-contrast, neon-accented dark theme will feel aggressive and off-brand on a bakery’s website. Extract the underlying principle, whether that’s “one accent colour only” or “soft borders instead of shadows”, and apply it to your own brand rather than reproducing someone else’s exact palette.

How to implement dark mode correctly (CSS and JS essentials)

The visual decisions only matter if the implementation holds up, and most dark-mode bugs come from skipping one of a small number of technical steps.

Start at the root. Setting color-scheme: light dark; on :root tells the browser which colour schemes your page supports, so native UI elements such as scrollbars, form controls and the browser’s default canvas background adapt automatically. This single declaration, combined with prefers-color-scheme media queries for your custom properties, is the foundation that MDN’s documentation recommends for detecting and responding to a visitor’s system-level theme preference.

A common mistake is applying color-scheme to body instead of :root. Browsers read the rendering context from the root element, so a body-only declaration leaves scrollbars and the initial canvas unthemed, which causes the page to flash the wrong colour for a fraction of a second before your CSS finishes applying.

That flash, known as FOUC, is the next hurdle. Modern web guidance from Chrome’s team recommends a small inline, non-deferred script placed in the document head that reads a saved theme preference from localStorage and sets it as a data attribute or class before any CSS loads. Because this script runs before the page paints, it prevents the jarring light-to-dark flash that users notice when a pinned preference loads late.

A practical implementation needs a few more pieces working together:

• Persist the user’s choice in localStorage so a manual override survives page reloads and return visits.
• Listen for system changes with window.matchMedia('(prefers-color-scheme: dark)').addEventListener(...) so the site updates live if someone changes their OS theme while your tab is open.
• Style form controls and scrollbars using accent-color and scrollbar-color, both of which respect color-scheme automatically once it’s set correctly.
• Handle SVGs deliberately: inline SVGs can use currentColor to inherit theme colours, but third-party icon sets often need a dedicated dark variant.
• Treat iframes and embeds as a separate problem, since embedded content from another domain won’t inherit your color-scheme and may need its own theme parameter or a wrapping background colour to avoid a jarring light rectangle on a dark page.

Progressive enhancement should guide all of this. Default to the system preference, fall back gracefully in older browsers that don’t support prefers-color-scheme, and never let a missing feature break the base experience. Google’s modern-web guidance treats this layered approach as the standard pattern for production sites, and it’s the same approach we build into every dark-mode project we deliver.

Accessibility and WCAG considerations for dark mode

Accessibility isn’t a finishing touch on a dark theme, it’s the frame the whole design sits inside, as explained in our article on web accessibility and SEO compliance. UK public sector websites are monitored for compliance with WCAG 2.2 AA, which sets a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text or non-text UI components, and those same thresholds are the sensible baseline for any commercial site, dark theme or not.

Dark themes fail these thresholds more often than light ones, usually because a designer judges contrast by eye rather than measuring it. A mid-grey that looks perfectly legible in isolation can fall below 4.5:1 once it’s set against a specific background shade, so every text and background pairing needs checking individually rather than assumed from a palette that “looks fine.” Our own guide to WCAG colour contrast walks through the calculation and testing workflow we use on client projects, and it applies equally to light and dark palettes.

Beyond contrast ratios, a handful of practical rules keep a dark theme genuinely usable:

• Never rely on colour alone to signal state, such as marking an error field only by changing its border to red; pair colour with an icon, label or pattern so the information still comes through for colour-blind visitors.
• Keep focus indicators clearly visible: a subtle focus ring that works on a white background can disappear entirely on dark grey, so test every interactive element with keyboard-only navigation.
• Test in Windows high-contrast mode and with colour-blindness simulators, since forced-colour modes can override your custom palette entirely and expose elements that depend on a specific colour to be understood.

The GOV.UK Design System’s colour guidance is a useful reference point here even for non-government sites, since it provides functional colour tokens, including dedicated inverse-text values, built specifically to meet these contrast rules on dark surfaces. Borrowing that token structure, functional names rather than arbitrary hex values, makes it far easier to audit a palette for compliance later.

Testing checklist and cross-browser pitfalls

A dark theme that looks correct in your design file can still break once it reaches real browsers, real operating systems and real assistive technology. A structured QA pass catches most of what a quick visual glance misses.

1. Run visual regression checks across browsers and OS theme settings, comparing how the same page renders in Chrome, Safari and Firefox under both light and dark system preferences, since rendering engines handle color-scheme slightly differently.
2. Check forced or automatic dark-mode features specifically. A documented issue thread on GOV.UK Frontend describes how Chrome’s Auto Dark Mode can recolour elements the developer never intended to theme, sometimes producing contrast regressions that only appear once the browser’s forced mode is active.
3. Inspect pseudo-elements and SVGs separately, since ::before, ::after and inline graphics are easy to miss in a manual click-through but often carry hardcoded colours that don’t respond to theme changes.
4. Run automated contrast checks using tools such as axe or pa11y across every page template, then follow up with a manual keyboard-only pass and a screen reader smoke test, since automated tools catch contrast failures but not confusing focus order or missing labels.
5. Test every embed separately, including iframes, maps and social widgets, since content from another domain won’t inherit your theme and can leave a bright white rectangle sitting awkwardly on an otherwise dark page.

Pro Tip: Keep a running checklist of every third-party embed on your site, since these are the components most likely to be forgotten during a dark-mode QA pass and the hardest to fix quickly once discovered in production.

Kukoo’s practical checklist: how we design dark-mode sites for clients

Dark mode decisions fit naturally into the collaborative four-step process we use on every branding and web project. We start with brand foundations, move into UI palette decisions, then build and QA, checking accessibility at each stage rather than bolting it on at the end.

• Brand foundations: we establish which brand colours genuinely work on a dark surface and which need adjusting, since a logo or palette built for white backgrounds rarely transfers without changes.
• UI palette: we draft functional colour tokens, text, background, accent, border, rather than a single fixed palette, so contrast can be tuned independently of brand colour choices.
• Build: our development work follows the color-scheme and prefers-color-scheme patterns outlined above, built to avoid FOUC and to persist user preference.
• QA: every project goes through contrast testing and cross-browser checks before launch, catching the regressions that only show up once real content is in place.

The trade-off we make most often is desaturating brand accent colours slightly for dark surfaces, since a colour that reads as confident on white can look harsh or glow unpleasantly on charcoal. Preserving the brand’s recognisability while still hitting WCAG thresholds is usually a small adjustment, not a redesign. You can see how this fits into broader UX thinking in our piece on enhancing user experience through visual design.

Impact of dark mode on brand identity and visual consistency

A dark theme changes how every brand asset reads, not just the background colour. Logos, in particular, are the first casualty of a careless dark-mode rollout. A mark designed with fine detail or subtle colour gradients on the assumption of a white backdrop can lose definition or clash once it sits on charcoal, which is why we treat logo adaptation as a design task in its own right rather than an automated inversion. Our piece on dark-themed logo trends looks at how brands have approached this shift without losing recognisability.

Visual consistency matters just as much as the logo itself. A brand’s colour palette, type pairing and spacing system should feel like the same brand whether someone lands on the light or dark version, which means defining both themes from the same design tokens rather than designing them as two separate systems that happen to share a logo. Photography and illustration style need the same scrutiny, since image treatments that look warm and inviting on white can read as murky or flat against dark grey.

Done well, a dark theme can strengthen a brand’s identity by giving it a distinct, premium feel that a purely light site can’t achieve on its own. Done carelessly, it dilutes recognisability. The difference usually comes down to whether the dark palette was designed deliberately from brand foundations, or generated as an afterthought once the light site was already finished.

Performance considerations when implementing dark mode

Dark mode itself adds very little weight to a page, but the way teams implement it can introduce real performance costs if they’re not careful. The inline theme-detection script needed to prevent FOUC should stay as small and simple as possible, since anything heavier delays the first paint rather than speeding it up.

Image assets are the bigger risk. Shipping separate dark and light variants of every photograph or illustration doubles the image payload unless you load them conditionally. Using the <picture> element with a prefers-color-scheme media condition, or lazy-loading the inactive theme’s assets only when needed, keeps page weight down while still giving each theme its own tailored imagery.

CSS custom properties are the most efficient way to manage theme switching, since toggling a handful of variables at the root is far cheaper than swapping entire stylesheets or duplicating component styles for each theme. Avoid JavaScript-driven style recalculations that touch every element on toggle, since that approach can cause visible jank on lower-powered devices, particularly on older mobile hardware. A well-structured token system lets the browser repaint efficiently without that overhead.

Finally, test theme switching speed on a genuinely low-powered device, not just a development machine. A toggle that feels instant on a desktop can stutter noticeably on a budget phone, and that’s exactly the kind of gap that separates a dark theme that feels considered from one that feels like an afterthought.

When not to use dark mode (brief editorial perspective)

Dark mode isn’t automatically the more modern or more accessible choice, and treating it that way causes more problems than it solves. Long-form editorial content, articles, documentation and anything meant to be read for several minutes at a stretch, often works better on a light background, since sustained reading research and decades of print convention both favour dark text on a light page for comfort over time.

Brand recognition is the other real constraint. If your audience associates your brand with a specific light palette, a full dark overhaul can make the site feel unfamiliar rather than fresh. A partial dark treatment, applied to a dashboard or a specific feature rather than the whole site, often delivers the benefit without the identity risk.

— Kukoo

How Kukoo can help deliver an accessible dark-mode website

If you’re weighing up whether dark mode suits your brand, we can take that decision off your hands entirely. Our UX/UI design and web design & development services cover everything from palette decisions through to a fully built, accessibility-tested theme, so you get a site that looks considered rather than bolted together.

Every project runs through the same collaborative process, with unlimited revisions on the design work, so a dark theme gets refined until it’s genuinely right rather than just shipped. If you’re adding dark mode to a site we haven’t built, our maintenance and improvement plans can layer it in without disrupting what already works. Get in touch and tell us about your site, we’ll help you work out whether dark mode earns its place.

FAQ

What is dark mode in website design?

Dark mode is a colour scheme that uses light text and UI elements on a dark background, typically deep grey or near-black, instead of the traditional dark-on-light layout. It’s usually offered as an alternative to a site’s default light theme, switchable by the user or triggered automatically by their system preference.

When should I offer dark mode on my website?

Dark mode tends to suit visual or media-heavy sites, interfaces used for long sessions, and brands with a bold or technical identity. The safest approach is to detect the visitor’s system preference using prefers-color-scheme and let them override it manually if they prefer the opposite.

What contrast ratio does dark mode need to meet for accessibility?

Dark mode text should meet the same WCAG 2.2 AA thresholds as any other content: a minimum of 4.5:1 for normal text and 3:1 for large text or non-text UI components. These ratios need checking for every specific text and background pairing rather than assumed from how a palette looks by eye.

How do I stop my dark mode site flashing the wrong colour on load?

This flash, known as FOUC, is usually prevented with a small inline script placed in the document head that reads the user’s saved theme preference before any CSS loads, combined with color-scheme: light dark set on :root. Guidance from Chrome’s web team recommends this pattern specifically to avoid the flash for users who have pinned a theme preference.

Does dark mode affect website performance?

Dark mode itself adds negligible weight, but shipping separate image assets for each theme can double your image payload if they’re not loaded conditionally. Using CSS custom properties for theme switching, rather than duplicating stylesheets or triggering full style recalculations, keeps the toggle fast even on lower-powered devices.

Sources

• GOV.UK Design System — colour
• MDN — @media (prefers-color-scheme)
• Modern web guidance — dark mode (GoogleChrome)

Recommended

• WCAG Color Contrast: 4.5:1 & Workflow for Designers & Product Teams
• Why design for accessibility boosts UK business success
• Web Page Design: Enhancing User Experience