HighLevel Custom CSS: The Complete Guide for Agencies

You want HighLevel to look like your own software, so you open the Custom CSS box, paste a few rules from a forum thread and save. The sidebar turns your brand color. A week later a client sends a screenshot: half the buttons are back to HighLevel blue, a dropdown has white text on a white background, and nobody on your team remembers which rule did what.

This guide is for agency owners and freelancers who want to use HighLevel custom CSS without that cycle. It covers every place HighLevel accepts custom CSS, what CSS can and cannot change, how to find selectors that survive updates, a safe install routine, how to organize a stylesheet you can still read in a year, and what to do when a release breaks your theme. GHL Dashboard Builder is an independent design service and is not affiliated with HighLevel; where our product is relevant we say what it does and what it does not do.

What is custom CSS in HighLevel?

Custom CSS is a stylesheet you write yourself and add to HighLevel so it loads on top of HighLevel’s own styles. It changes how existing things look: colors, fonts, sizes, spacing, borders, shadows, and whether something is shown at all. It does not change HighLevel’s features, data or permissions.

CSS stands for Cascading Style Sheets, the language every website uses for its appearance. A rule has two parts: a selector, which says which elements on the page to style, and declarations, which say how. In .sidebar a { color: #1D4ED8; }, the selector is .sidebar a (every link inside an element with the class sidebar) and the declaration sets the text color.

HighLevel provides a dedicated place for this at agency level. Its help article on agency company settings describes Custom CSS as being for styling the platform, hiding elements and adjusting branding, and Custom JavaScript as being for things such as live chat widgets, analytics and tracking pixels. The same article carries the warning that shapes everything in this guide: custom code is powerful but unsupported, and changes to HighLevel’s core interface may break it.

That warning is not a reason to avoid custom CSS. It is a reason to write it in a way that is easy to check, easy to fix and easy to remove.

Why agencies use it at all

HighLevel’s built-in white-label settings change your logo, domain and system links, but not the colors, menu or layout of the dashboard. Our complete guide to white-labeling HighLevel walks through that identity layer in detail. Custom CSS is the next layer: it is what makes a client’s daily view feel like your product rather than a resold login.

Where can you add custom CSS in HighLevel?

There is not one Custom CSS box in HighLevel but several, and each styles something different. The agency-level box under Settings, Company, Whitelabel styles the HighLevel app your users log in to. Funnels, websites, forms, surveys, quizzes and community groups have their own fields that style what your clients’ customers see.

Mixing these up is the most common reason a rule “does nothing”. CSS pasted into the agency box will not change a funnel page, and CSS added to a form will not touch the dashboard. The table below maps the main locations, using the menu paths in HighLevel’s help center at the time of writing.

A few details from HighLevel’s own articles are worth knowing before you start:

• Forms load inside an iframe when embedded on a page. HighLevel’s guide to custom CSS for forms, surveys and quizzes explains that CSS in the funnel or website settings can style the container around a form but not its fields or buttons; those need CSS inside the form itself, followed by Save and Publish.
• Community groups have a test step. The article on custom CSS and JavaScript for groups describes a Test Preview before you turn Live Mode on, and a way to load the community with custom code switched off by adding customCode=false to the address, which is useful when you are not sure whether your code caused a problem.
• Funnel and website code is the first suspect when a page misbehaves. HighLevel’s troubleshooting FAQ for funnels and websites suggests removing custom code, tracking code and custom CSS when you investigate rendering problems.

The rest of this guide is about the first row: agency-level CSS that styles the HighLevel app. That is where branding happens, and where most of the risk sits.

What can custom CSS change in the HighLevel dashboard?

CSS can restyle almost anything that is already on the screen and has a selector you can rely on. That covers the visual identity of the app: colors, typography, shape, spacing and visibility. It cannot add new content with behavior, change wording reliably, or reach parts of HighLevel that are not rendered as ordinary web pages in the browser.

HighLevel’s agency settings article is specific about the limits. At the time of writing, it lists the iOS and Android mobile apps, React pop-ups such as payment modals, back-end generated PDF invoices and receipts, core drag-and-drop builder interface elements, and any element without a stable class or data-id as things you cannot customize with CSS. That last item is the key to writing CSS that lasts, and we come back to it in the selector section.

A useful mental model

Think of agency CSS as a coat of paint and a set of signs. You can repaint every wall, change the font on every sign and cover the doors you do not want people to use. You cannot move walls, add rooms or change what happens behind a door. If a client request is about behavior (“can the calendar send a different reminder?”) it belongs in HighLevel’s settings or workflows, not in your stylesheet.

Why renaming the menu is not a CSS job

You will find forum snippets that “rename” menu items with CSS by shrinking the original text to zero and inserting new text with a ::after pseudo-element. It appears to work, but it has three problems. Screen readers and browser translation still read the original label. Any change to the menu’s markup breaks it. And every rename needs another hand-written rule. Renaming properly means changing the label text with JavaScript after the menu loads and again whenever HighLevel redraws it, which is why industry wording is usually handled by a theme rather than a stylesheet.

How do you find selectors that survive HighLevel updates?

Choose the most stable thing on the element, keep the selector short, and avoid anything that describes position or build-generated names. HighLevel’s own list of limits says elements without a stable class or data-id cannot be customized, which tells you what “stable” means in practice: a class name or data attribute that describes what the element is, not where it happens to sit.

How to inspect an element

1. Open HighLevel in Chrome, Edge or Firefox and go to the screen you want to style.
2. Right-click the element and choose Inspect. The developer tools open with that element highlighted.
3. Look at its attributes: class, id, any data- attributes, role and aria-label.
4. Walk up a level or two in the tree to see the container it belongs to.
5. In the Styles panel, note which existing rule sets the property you want to change. That rule’s selector tells you how specific yours must be.
6. Test your rule live in the Styles panel before you paste anything into HighLevel.

Rank selectors by how likely they are to last

The selectors in that table are illustrations of each pattern, not HighLevel’s real markup. Always inspect the current page; HighLevel’s structure differs between screens and changes over time.

Specificity, briefly

When two rules set the same property on the same element, the browser applies the one with higher specificity, a score based on how many IDs, classes or attributes, and element names the selector contains. If specificity is equal, the rule that comes later wins. MDN’s page on specificity explains the calculation with examples.

In HighLevel this matters because your CSS competes with the app’s own stylesheets. If your rule loses, the usual fix is to make it slightly more specific, for example by prefixing it with a stable container ([data-testid="sidebar"] a instead of a). Reach for !important only when that fails, and comment why.

/* Sidebar links: brand text color on hover.
   !important: example of beating a more specific built-in hover rule.
   Say in this comment which rule you are overriding. */
.sidebar-nav a:hover {
  color: var(--brand-600) !important;
}

Signs a selector will break soon

• It is longer than three or four parts.
• It contains nth-child, nth-of-type or a run of div > div > div.
• It includes random-looking characters.
• It only works on one screen even though the element appears on several.
• You copied it from a post written before HighLevel’s last redesign of that screen.

How do you install custom CSS in HighLevel safely?

Copy what is already there, paste the new code, save, and check in a separate browser tab with a non-admin user. The whole routine takes a few minutes, and the first step, saving a copy of the existing code, is the one that turns a bad release into a two-minute rollback instead of an afternoon of guesswork.

Menu paths below match HighLevel’s help center at the time of writing.

Before you paste

1. Write or export the new CSS into a file on your computer or in your code repository, never only in HighLevel.
2. Run it through a CSS validator or your editor’s linter to catch a missing brace, which can silently disable every rule after it.
3. Decide which sub-account you will test on and which non-admin user you will log in as.

In HighLevel

1. Switch to the agency view.
2. Open Settings, Company, then the Whitelabel tab.
3. Scroll to Custom Code.
4. Copy everything currently in Custom CSS and Custom JavaScript into a dated text file. This is your rollback.
5. Paste the new CSS into Custom CSS.
6. Save. If you also changed JavaScript, HighLevel shows a warning about third-party scripts; read it and continue only if you trust the code.

After saving

1. Open a sub-account in a new tab and hard-refresh the page.
2. Walk through the screens your clients use most: dashboard, conversations, calendars, contacts, opportunities, payments and settings.
3. Open every dropdown, modal and date picker you can find. Pop-ups are where unreadable text hides.
4. Narrow the window to tablet width.
5. Log in as a non-admin user, because some menus and pages differ by role.
6. Keep the rollback file until the theme has run for at least a week without complaints.

Before you paste3 steps

In HighLevel6 steps

After saving6 steps

Source: Step counts from the install walkthrough in this guide.

Fifteen steps sounds like a lot for pasting a stylesheet. Most take seconds, and each one exists because skipping it causes a recognizable problem later: no rollback copy, a syntax error that disables half the theme, or a dropdown nobody checked.

How should you organize a HighLevel stylesheet so it stays maintainable?

Put your brand values in variables at the top, group rules by screen, comment every override, and keep the source outside HighLevel. A stylesheet organized this way can be updated by someone who did not write it, which is the real test of maintainability for an agency with staff turnover or freelancers.

Use custom properties for your brand

CSS custom properties, often called CSS variables, let you define a value once and reuse it everywhere. MDN’s guide to custom properties covers the syntax. For an agency, this means a rebrand, or a different color for a second brand, is a change to a handful of lines rather than a search through hundreds.

/* ============ 1. Brand tokens ============ */
:root {
  --brand-600: #1D4ED8;   /* buttons, active menu item: white text passes */
  --brand-400: #3B82F6;   /* accents, icons, thin borders only */
  --sidebar-bg: #0F172A;
  --sidebar-text: #E5E7EB;
  --radius: 10px;
  --font: "Inter", system-ui, sans-serif;
}

/* ============ 2. Sidebar ============ */
/* ============ 3. Header ============ */
/* ============ 4. Buttons and tabs ============ */
/* ============ 5. Tables and lists ============ */
/* ============ 6. Hidden items ============ */

If a HighLevel release renames a selector, you fix one rule in the right section. If you want a darker sidebar, you change one token.

House rules that save time later

• One comment per override. Say what the rule changes and, where it uses !important, what it beats.
• Group by screen, not by property. All sidebar rules together, all calendar rules together. When a screen changes, everything that might break is in one place.
• No rule without a reason. Delete experiments. Dead rules confuse the next person and can match new elements after an update.
• Version the file. A Git repository or even dated copies in a shared drive gives you history and a rollback for every change.
• Record the date you last checked each section against the live interface. It tells you where to look first after a release.
• Keep JavaScript separate. If you need a few lines for menu renames, keep them in their own file with the same comment discipline.

Hiding things: be deliberate

Hiding a menu item with display: none is one of the most popular uses of custom CSS, and one of the easiest to regret. Keep a list of everything you hide and why. Hiding is visual only: the page still exists and a user who has the address can still open it, so use HighLevel’s user permissions when access genuinely needs to be restricted.

How do you keep a theme readable and accessible?

Check the contrast of every text color against every background it sits on, keep focus outlines visible, and avoid motion that cannot be turned off. Branding changes colors in dozens of places at once, and one pale brand color can make buttons, tags and active menu items hard to read across the whole app.

The W3C’s explanation of contrast success criterion 1.4.3 sets a minimum contrast ratio of 4.5 to 1 for normal text and 3 to 1 for large text. We calculated the ratios for some typical color pairs with the WCAG formula. Several common brand colors fail with white text, and dark text on the same color often passes easily.

White on deep blue #1D4ED86.70 to 1

White on mid blue #3B82F63.68 to 1

White on amber #F59E0B2.15 to 1

Near-black #111827 on amber #F59E0B8.26 to 1

Light grey #9CA3AF on white2.54 to 1

Light text #E5E7EB on dark sidebar #1F293711.86 to 1

Source: Calculated with the WCAG 2.2 contrast formula, October 2026. Minimum for normal text: 4.5 to 1.

Three practical rules follow from those numbers:

• Keep two shades of your brand color. A darker one for anything with text on it, the original for accents and icons.
• Do not lighten secondary text too far. Light grey on white looks elegant in a mock-up and fails in daylight on a laptop.
• Check states, not just defaults. Hover, active, disabled and selected states each have their own colors in your theme, and each needs a check.

Focus, motion and size

• Never remove focus outlines with outline: none unless you replace them with something equally visible. Keyboard users rely on them to see where they are.
• Respect reduced motion. If your theme adds transitions or a shimmer, wrap them in a prefers-reduced-motion media query so people who have asked their system for less motion get it.
• Do not shrink fonts to fit more in. HighLevel screens are dense already; a smaller base size makes them harder for everyone.

Why does custom CSS break after HighLevel updates, and what do you do?

Because your selectors describe HighLevel’s page structure, and HighLevel changes that structure when it improves a screen. HighLevel says so directly: custom code is unsupported, and changes to the core interface may break it. The fix is a routine, not a one-off: notice quickly, find the rule, update the selector, and keep a rollback ready.

Most breakages fall into a few patterns.

A release-day routine

1. Watch for changes. Follow HighLevel’s changelog and release notes, and note any screen that was redesigned.
2. Run your screen checklist within a day of a significant release: the same screens, dropdowns and roles as in the install routine.
3. Disable to diagnose. If a screen looks broken, check whether the problem is yours: clear the Custom CSS box for a few minutes (your rollback file makes this safe) or compare with an account that runs no theme. If the problem remains without your code, it is HighLevel’s, and their support team is the place to report it.
4. Fix the selector, not the symptom. Do not stack a new !important rule on top of a broken one. Replace the broken selector with a more stable one.
5. Update the “last checked” date for that section of your stylesheet.

Hosted versus pasted code

If you paste the full stylesheet into every agency account you manage, a fix has to be repeated in each one. Loading the stylesheet from one address, so that every account reads the same file, means one fix reaches all of them. That is a design decision worth making early if you manage more than one agency account or resell setups to other agencies.

Can you give one sub-account its own CSS?

Not with CSS alone. Agency-level custom code loads for the HighLevel interface your users see, including every sub-account, and a stylesheet has no way to know which sub-account is open. To give one client a different look, a few lines of JavaScript need to check the sub-account’s Location ID and switch the design on only there.

The usual approach looks like this:

1. Find the sub-account’s Location ID. It appears in the web address when you open the sub-account in HighLevel.
2. Write all of that client’s rules under one class, for example .client-acme, so they apply only when that class is present on the page.
3. Add JavaScript that reads the current address, and if it contains that Location ID, adds the class to the page; if not, removes it.
4. Re-run the check whenever HighLevel changes pages without a full reload, since HighLevel moves between screens inside the app.
5. Test the target sub-account, a different sub-account and the agency view, so you know the design stays where it belongs.

When this is worth the effort:

• A premium client pays for a fully branded platform with its own colors.
• A pilot lets you test a new design on one friendly client before everyone gets it.
• A mixed agency serves several industries and wants each to have suitable wording and colors.

Our setup guide for dental and medical practices shows how this plays out when only the healthcare clients in an agency get a clinical design.

Should you write the CSS yourself, hire a developer or use a builder?

Write it yourself if you know CSS, enjoy it and have time for upkeep. Hire a developer if you need something unusual and can brief and review the work. Use a builder or design service if you want a finished, tested look quickly and would rather spend your time on clients. Each route works; they differ in where the effort and the risk land.

Questions to answer before you choose:

• How many accounts will run this theme? One agency account is easy to maintain by hand; several are not.
• Who will be on call after a release? If the answer is “whoever notices”, choose a route where someone owns updates.
• Do clients need more than colors? Industry wording, other languages and right-to-left layouts are JavaScript work.
• What is your time worth? Hand-styling every screen, dropdown and state can take days before the first client sees it.

How does GHL Dashboard Builder handle custom CSS?

GHL Dashboard Builder is a visual builder and design service that generates the CSS and JavaScript for a branded HighLevel and installs it through the same Custom Code boxes described above. You make design choices on a live copy of HighLevel’s screens; the code comes from those choices. Here is what it covers, taken from the product as it stands today.

• Colors and type. A full color system for primary, accent, sidebar, header, surfaces and status colors, plus fonts and favicon.
• Sidebar and header. HighLevel’s own sidebar in your colors, colored or 3D menu icons, hover menus, a top bar option and a branded sub-account switcher.
• Buttons, cards and forms. Your brand color on HighLevel’s buttons, tabs, tags, dropdowns and pipeline, with several button styles and custom borders and corners.
• Menu editor. Rename, reorder, hide and badge any of HighLevel’s 19 menu items, without the CSS workarounds described earlier.
• Languages. The menu and navigation in 15 languages, with right-to-left layouts for Arabic, Urdu and Hebrew. Our guide to white-labeling HighLevel in the United Arab Emirates shows what that means for an Arabic-speaking team, and the languages page lists them all.
• One sub-account or all. Apply the design everywhere or only to chosen sub-accounts.
• Two-line install. One CSS line and one JavaScript line in HighLevel. The code is small, typically 15 to 25 KB, changes styling and menu labels only, and does not read or send your clients’ data.

It is still custom code in HighLevel, so the same caveat applies: a significant HighLevel update can occasionally require a refresh of the theme.

What each plan lets you change in the builder after you buy is set in the product. Starter opens 9 editor sections, Pro adds layout, navigation, login, effects and language for 14, and Agency opens all 15, including an advanced section for adding your own CSS and JavaScript alongside the generated theme.

Starter ($149 one-time)9 sections

Pro ($349 one-time)14 sections

Agency ($99 per month)15 sections

Source: GHL Dashboard Builder plan access, October 2026

If you prefer to start from a finished look, the templates gallery has 20 designs. Atlas, for example, keeps HighLevel blue with a warm sand accent on a slate sidebar, which suits agencies whose clients already know the standard interface. The features page lists everything that installs into HighLevel and what is preview only.

A worked example: from forum snippets to a maintainable theme

This is an illustrative example, not a customer story. It shows how the practices in this guide change a typical hand-made theme.

The starting point. An agency has 140 lines of CSS collected over a year. There are no comments. Eleven rules use !important. Several selectors contain nth-child. Two rules set the same sidebar color with different values. Nobody knows whether the calendar rules still match anything.

Step 1: save and freeze. The current code goes into a dated file. No changes are made in HighLevel until the new version is ready.

Step 2: audit. Each rule is tested in the browser’s developer tools against the live interface. Rules that match nothing are deleted. Duplicates are merged.

Step 3: tokens. Every color, radius and font value moves into custom properties at the top. The brand blue turns out to be used for white button text at 3.68 to 1, so a darker shade is added for buttons and the original kept for accents.

Step 4: selectors. Position-based selectors are replaced with ones built on descriptive classes or data attributes found by inspection. !important stays only where HighLevel’s own styles require it, each with a comment.

Step 5: structure. Rules are grouped by screen with a “last checked” date on each section.

Step 6: install and test. The routine from the install section runs on one test sub-account with a non-admin user, then on everyone.

The result. The stylesheet is shorter, and the next time a HighLevel release changes the conversations screen, the fix is in one clearly labeled section. Nothing in this example changed how HighLevel works; it changed how quickly the agency can respond when HighLevel changes.

What to do next

1. Save a copy of your current custom code today. Open Settings, Company, Whitelabel in the agency view, copy both Custom Code boxes into a dated file, and keep it somewhere your team can find.
2. Audit your selectors. Inspect each rule against the live interface, delete what matches nothing, and replace position-based selectors with stable ones.
3. Move your brand into custom properties and check the contrast of every text color on every brand surface.
4. Write down a release-day checklist of the screens, pop-ups and user roles you will test after each significant HighLevel update.
5. Compare the effort with the alternatives. Try your colors on HighLevel’s screens in the free builder and look at the plans before committing to another round of hand-written CSS.

If you have a question about a specific screen or setup, the FAQ covers installation and removal, and you can contact us about anything it does not answer.