How to Change Fonts and Colours in HTML Templates

Change fonts and colours in an HTML template through the stylesheet or design settings that already control them. Identify shared variables first, make a small set of deliberate changes and review every affected page type. Check font permissions, readable contrast and layout changes before publishing.

A branding update is more than replacing a few colour codes. A new typeface can change line lengths and button widths, while a new accent colour can make existing text hard to read. Treat appearance and usability as one task.

Find the existing design controls

Search the CSS for custom properties, font-family declarations and the current colour values. Some templates define a small set of tokens near the beginning of a stylesheet; others use configuration files or a CSS framework.

Read the documentation before adding overrides. If the package compiles CSS from source, edit the source rather than only the generated stylesheet.

The HTML template overview explains the broader customisation workflow. Establish an unchanged preview and keep a recoverable copy before making global design edits.

Use shared colour variables when available

A template may define values such as these:

:root {
  --page-bg: #ffffff;
  --text-main: #172a39;
  --brand: #215c42;
  --brand-contrast: #ffffff;
}
.button {
  background: var(--brand);
  color: var(--brand-contrast);
}

This example illustrates a centralised system. It is not a promise that your package uses these names. Map the real variables and their uses before changing them.

The MDN custom properties guide explains how CSS variables participate in the cascade. Remember that a token can affect several components, including states you do not see on the homepage.

Plan a small, functional palette

Choose colours for backgrounds, main text, secondary text, links, actions and borders. Include the text colour used on filled buttons rather than selecting the background alone.

Test actual combinations. A pale brand colour may work as a decorative panel but fail as the colour of small text on white. A dark button may need different hover and focus treatment after a palette change.

Do not use colour as the only indicator of an error, selected option or link. Supporting labels, shapes or underlines help communicate meaning independently of hue.

Choose and license the font

Confirm that the chosen font can be used on the website under its applicable licence. A desktop font file is not automatically licensed for web embedding.

Check which weights and styles the design uses. Loading one regular file while asking CSS for several weights can produce an appearance different from the intended design. Loading every available weight can create unnecessary downloads.

Consider a suitable fallback stack. Visitors should still receive readable content while the preferred font loads or if it fails. Select fallbacks with reasonable proportions for the layout.

Load a local font deliberately

A self-hosted font can be declared with font-face. For example:

@font-face {
  font-family: "Project Sans";
  src: url("../fonts/project-sans-regular.woff2") format("woff2");
  font-style: normal;
  font-weight: 400;
  font-display: swap;
}
body {
  font-family: "Project Sans", system-ui, sans-serif;
}

Use a real licensed file and a path relative to the stylesheet. This example defines one weight; add other weights only when you have the relevant files and need them.

The MDN font-face reference describes the descriptors. Preserve the package’s existing loading approach unless you have a reason to change it.

Review layout after typography changes

Check the longest navigation label, hero heading, card title and button text. Fonts with different proportions can introduce wrapping or overflow even when the size stays the same.

Read a long paragraph as well as headings. Appropriate line height and line length matter for sustained reading. Avoid shrinking all text to restore a layout designed around a much narrower typeface.

Inspect narrow, medium and wide viewports. The responsive template guide explains why global changes need checks beyond one desktop screenshot.

Test interactive and unusual states

Review hover, focus, selected, disabled and error states. Open menus and accordions, trigger form validation and inspect links within coloured panels.

Check any dark footer or image overlay separately. A colour that works on a white content area may be unreadable over a photograph. Test the actual images you will publish rather than relying on the original demo crop.

If a template includes dark mode, update both palettes intentionally. Do not assume that a single global replacement creates readable combinations in both appearances.

Keep the changes maintainable

Document the final palette and font sources in the project. Remove experimental overrides that are no longer used and retain licence notices for embedded assets.

Follow the HTML editing workflow for preview and publication checks. Use the HTML catalogue to compare designs whose original typography and structure are already close to your needs. A restrained, well-tested brand adaptation is easier to maintain than a large collection of conflicting style patches.

If another person will maintain the site, include a short note showing where the shared tokens live and which font files are required. That prevents later edits from reintroducing the original palette or loading duplicate font resources. Keep the note specific to the final project rather than a generic styling tutorial.