Dark mode is one of those features that sounds like a cosmetic preference and turns out, in daily use, to matter substantially. For users who spend the bulk of their working hours inside a single application — operations staff, customer support agents, anyone whose job is to live inside the system — the difference between a well-tuned dark theme and a glaring white screen is the difference between a comfortable eight-hour shift and a day that ends with a headache. It's also one of those small features whose presence quietly signals that the platform's authors thought about the people who would actually use it, rather than treating them as interchangeable consumers of whatever default the framework happened to ship with.
Dark mode is a first-class palette, not a filter. A naive dark mode inverts everything and hopes for the best — which produces harsh contrasts on images, muddy colors on charts, and borders that vanish into the background. A proper dark mode is designed: each color has a considered dark-theme counterpart that maintains the intended meaning and contrast; status indicators stay distinguishable; destructive actions still feel destructive; the subtle visual hierarchy that guides the eye through a page still works. The platform's dark theme has been designed that way from the start, rather than generated automatically from the light one.
Every component has a dark-mode treatment. Tables, form inputs, modals, dropdowns, buttons, date pickers, file uploaders, rich-text editors, sidebars, tabs, tooltips, badges, progress bars, the application shell, the navigation, the header — all of it. There isn't a corner of the application that suddenly flips to white when the user enables dark mode. That completeness matters because a half-implemented dark mode is worse than a pure light theme: every unstyled modal or form is a shock to the eye that defeats the purpose of dark mode in the first place.
Theme preference follows system by default. When a user's operating system is set to dark mode — say, because they've scheduled it for evening hours — the platform follows along. When the system flips back to light, so does the platform. Users who don't care to think about theme at all get a sensible experience based on what their device already knows about their preferences. Users who do care can override: force light regardless of system, force dark regardless of system, or follow system.
Per-user persistence keeps the choice consistent across devices. A user who prefers dark mode on their office desktop will see dark mode on their laptop at home, in the browser tab they open on a colleague's machine, on the phone they check email on. The preference is tied to the user, not to the device; changing it in one place changes it everywhere. For users who have a definite preference, that consistency is what keeps them from having to reconfigure every new context they encounter.
Tenant-level defaults let operators set a reasonable starting point for their user population. A tenant serving users in a visually-demanding control-room environment might default to dark mode; a tenant in a traditional office setting might default to light. The tenant default is what new users experience before they've expressed a preference of their own. Individual users can override in either direction; the tenant default is just the starting point, not a forced choice.
Quick toggle in the top bar is the path for users who switch themes situationally. A morning in sunlight might call for light mode; an afternoon in a darkened meeting room might call for dark; a late evening session definitely calls for dark. The toggle is one click in the application header, with an immediate effect across the whole interface — no page reload, no loss of state, no interruption to whatever the user was working on. For the users who want to match their environment minute by minute, the toggle makes it frictionless.
Canvas-page support is the feature that keeps dark mode from falling apart at the boundary between platform features and implementer-built content. Custom canvas pages — built with the canvas page builder by implementers on each tenant — inherit the theme automatically through theme variables. Blocks, typography, backgrounds, and accents on custom pages respect the user's chosen theme without requiring the implementer to do anything special. That inheritance is what makes dark mode genuinely complete: even the tenant-specific surfaces get it right, without per-page effort.
Data visualizations get palettes tuned specifically for dark backgrounds. A chart that looks crisp on a white background often looks muddy on a dark one, and vice versa; the platform's charts use theme-appropriate palettes that maintain distinguishability and contrast in both modes. A pie chart still shows clearly differentiated slices. A line chart still has readable axes. A heatmap still conveys intensity. Users shouldn't be forced to squint at their data just because they prefer a dark interface.
Print and export intentionally use the light theme. A PDF generated from a canvas page, a spreadsheet exported from a view, a document printed to paper — these all use the light theme by default, because black ink on white paper is what printed output is for, and because a dark PDF attached to an email looks broken. The user can override this for specific cases, but the default matches what print media actually expects. That's the kind of small default decision that separates a dark mode that was thought through from one that was bolted on.
Form inputs, modals, and tables deserve a specific mention because they're where many dark-mode implementations fall apart. Form inputs in the platform's dark theme are clearly distinguished from the page background but not so stark that they fight the eye. Modals have appropriate elevation cues that work on dark as well as light. Tables have alternating row treatment that reads naturally in both themes. The small visual cues that help users navigate complex interfaces survive the theme switch intact.
Dark mode isn't a gimmick. For users who spend long hours in the platform, it's a daily comfort; for users who don't, it's a nice-to-have that costs them nothing. In either case, it's one of the features that demonstrates, at a glance, whether a platform's authors were thinking about the humans who would live inside it. We were. For the surrounding topics, the canvas page builder article covers how custom pages participate in the theme system, the views article covers how data tables and boards look in both themes, and the charts documentation covers the color palettes used by data visualizations. Comfortable hours, long sessions — that's what dark mode is for.