The Zendesk Theme in Guide

Every Guide help centre runs a theme. Understanding the three layers of one tells you exactly how far you can go before you need a developer.

Start free trial All guides

The three layers of a Zendesk theme

A Zendesk theme is not one thing. It is a stack, and knowing which layer a change lives in tells you the cost of making it.

Settings. A panel of controls the theme author exposed: logo, colours, fonts, hero image, a few toggles. Editable by anyone, no code, no risk. Most brand alignment happens here.

Templates. Handlebars files, one per page type, using Zendesk's own helpers to output articles, sections, breadcrumbs and the request form. This is where layout changes live and where a theme becomes a maintenance commitment.

Assets. Your CSS and JavaScript, plus images and fonts. CSS is where most visual customisation actually happens, and it is the layer most likely to break quietly when Zendesk changes markup.

If a change can be made in settings, make it in settings. The gap in ongoing cost between layer one and layer two is enormous and nobody budgets for it.

Copenhagen, the standard theme

Copenhagen is the default theme every Guide instance starts with. It's genuinely decent: responsive, accessible enough, sensible information hierarchy, and it gets updated by Zendesk when Guide changes.

That last point is the one people miss. A stock Copenhagen keeps working. The moment you copy it and start editing templates, you own a fork, and Zendesk's updates stop arriving. Six months later a new Guide feature does not appear on your help centre and nobody remembers why.

So the honest advice: stay on Copenhagen with settings and a modest CSS override for as long as you possibly can. Plenty of very good help centres are exactly that.

When you outgrow settings

There are legitimate reasons to go further, and there are vanity reasons. The legitimate ones tend to be structural.

A different homepage layout because your categories do not fit the default grid. A custom request form experience. Extra navigation because you run several products under one brand. Embedding a status widget or a support hours banner. Restructuring the article page to put a table of contents where people will actually see it.

The vanity reasons are animation, unusual fonts and a hero image the marketing team chose. None of those change deflection. Some of them slow the page down, which does change deflection, in the wrong direction.

How custom themes get built

The mechanics are more developer-friendly than people expect. A theme is a folder of files with a manifest, and Zendesk provides a command line tool for local development so you can preview against your real content rather than editing in a browser textarea.

Themes are versioned in the templating layer, so a theme written against an older version keeps working while new helpers arrive in newer ones. Upgrading a theme across versions is real work, not a checkbox.

Two practical rules. Keep the theme in git, because the Guide interface isn't version control and someone will overwrite something. And keep your customisations in your own CSS file rather than scattered through the templates, so an upgrade is survivable.

Custom theme upload and multiple stored themes are plan dependent. Check current Zendesk docs against your Guide plan before designing anything, since finding out afterwards is a bad conversation.

Buy, build or hire

Marketplace themes cost a few hundred dollars and solve the "Copenhagen doesn't fit our brand" problem in an afternoon. Before you buy, check two things: is it actively maintained against Guide changes, and can a non-developer edit its settings. A gorgeous theme that only its author can update is a liability.

Hiring out makes sense when you need structural changes and have nobody in-house who will still be around in a year. Specify the handover: source in your repository, documented settings, a written note of every place Zendesk markup is depended on.

Building in-house is right if you already have front-end people and the help centre matters commercially. It is wrong if the plan is for one enthusiastic support manager to learn Handlebars in their spare time.

Whichever route you take, agree on a rollback plan before you go live. Guide lets you preview a theme against real content and switch the published one back, and knowing that in advance turns a launch from an event into a change.

For what to actually change once you can change anything, the help centre themes guide covers which customisations move the numbers.

FAQ

Frequently asked questions

How far does Zendesk theme customization go?

As far as you want, once you fork. Zendesk theme customization through settings covers colours, fonts and home page blocks, and the Zendesk templating API is what you edit when the layout itself has to change.

What is the Copenhagen theme?

The standard Zendesk Guide theme, shipped with every help centre and maintained by Zendesk. Customising it through settings keeps those updates; forking it does not.

Can I edit Zendesk theme code directly?

Yes, themes are Handlebars templates plus CSS, JavaScript and assets. Zendesk also provides a CLI for local development. Custom theme upload depends on your Guide plan.

Will a custom theme break when Zendesk updates Guide?

It can. Once you fork, you own the maintenance. Keep customisations isolated in your own stylesheet so upgrades stay manageable.

Are marketplace themes worth buying?

Often, if the default genuinely does not fit. Check that it's actively maintained and that its settings are editable without touching code.

Can I have more than one theme?

You can store several and switch the live one, and each brand has its own theme. The number you can store varies by plan, so check the current docs.