Squarespace
Custom Code SOS

Three reasons, in order of how often I see them on client sites:

You're using the wrong selector. Squarespace's class names are not intuitive, they're not documented in one place, and they change between versions. If your code is correct but nothing's happening, the selector is the first thing to verify. I made a free tutorial on how to find the right one at insidethesquare.co/squarespace-id-finder.

Something else is overriding your code. Squarespace loads stylesheets in a specific order, and your custom CSS panel loads relatively early. That means later styles can outrank it. Adding !important to your property value tells the browser to prioritize your code.

Squarespace's own design panel is overriding it. This is the 2026 plot twist, and it gets its own section below.

Squarespace shipped a lot of new design controls in the last year. Most of these are wins for designers: faster than code, mobile-responsive out of the box, easier to hand off to clients. They can also conflict with custom CSS in ways that look like your code stopped working.

The most common conflicts I see right now:

Block Transforms (rotate, scale, skew, offset). Released as part of the 2025 Finish Layer update. When you use the Transforms tool on a block, Squarespace writes those values as inline styles directly on the element. Inline styles outrank anything in the CSS panel.

Shape block stroke. Shape blocks have a native stroke (border) control in the Styling panel. If you set a stroke there, it will override CSS targeting the same property.

Section backgrounds. Native section background colors and images apply with high specificity. CSS background rules on the same section often get overridden.

Native font upload. Squarespace now lets you upload custom fonts directly in the Fonts panel. If you've uploaded a font there AND you have an @font-face rule in custom CSS for the same font, the native version usually wins.

The fix: add !important to the property you want to control, like this:

#block-your-block-id {
  transform: rotate(0deg) !important;
  border: none !important;
}

The better fix: ask whether you still need the code. If the native control does what you want, use the panel. It's faster, mobile-responsive by default, and easier for clients to maintain. The custom code you write in 2026 should be doing things the panel can't, not duplicating things the panel already does.

Most AI tools were trained on general web development, not on Squarespace specifically. They know CSS in theory. They don't know Squarespace's class structure, ID patterns, or the differences between 7.0 and 7.1.

The most common AI failures I see on Squarespace sites:

Made-up selectors. The AI guesses a class name that sounds reasonable but doesn't exist on the platform.

7.0 code applied to 7.1 sites. A lot of older tutorials are still floating around online, and general-purpose AI tools learned from them. The selectors and underlying page structure are different between versions.

Missing Squarespace context. Code that would work on a custom-built site but doesn't account for how Squarespace renders the page, loads stylesheets, or names its elements.

The fix isn't to stop using AI. The fix is to use AI that knows Squarespace.

That's why I built Custom Codey: an AI assistant trained specifically on Squarespace 7.0 and 7.1. It knows the class structure, it writes code that works on the version you're using, and it doesn't invent selectors that don't exist. $30 lifetime access, no subscription. Get it at customcodey.com

Squarespace is letting you know your code has a small mistake.

You’ll notice this error message the second you start to add code. The CSS panel is super impatient and it tries to process your code before you even finish it.

if you’re still getting an error after the full code has been added, it might be because of these causes:

• A missing curly brace. The squiggly ones { } come in pairs. Every opening one needs a closing one.

• A missing semicolon. Each CSS line needs a ; at the end to separate it from the next one.

• A typo in a property name or value.

The error message goes away as soon as the code is grammatically correct, even before you save.

Here's the structure to follow:

.your-selector {
property: value;
property-two: value
}

Syntax errors are not a sign you're doing something wrong. They show up every time anyone writes code, including me. They're the editor's way of helping you catch the small thing before you save it.

Squarespace uses two main ways to identify types of content: classes and IDs.

Classes apply to a group of similar items (every button, every image block, every blog summary item).

IDs apply to one specific item (this section, that block, that page).

If you want a working reference of the most common Squarespace selectors organized by what they style, I keep a library of over 500 of them in the Squarespace CSS Cheat Sheet at insidethesquare.co/css

If you want to use the ID approach, you can use browser developer tools (right-click → Inspect) or the free Squarespace ID Finder chrome extension from Will Myers available at insidethesquare.co/chromeext

Squarespace's custom CSS panel previews changes live in the editor as soon as you start typing. Your changes won't appear on the public site until you click Save.

For more aggressive testing, you can use a hidden page on your site, or work in a Squarespace trial site (free, no time limit on building) before publishing changes to a live client site.

Good news first: Squarespace now offers native custom font upload in the Site Styles panel (a 2025 update). You can upload .woff, .woff2, or .ttf files directly, no code required. If you haven't tried the native uploader yet, start there.

If you're using a CSS-based approach (@font-face, custom font-family declarations), check these in order:

1. Make sure the font file is uploaded to your Squarespace site as a custom file, not linked from an external host.

2. Confirm that the font-family name in your CSS matches exactly what you named the font on upload.

3. Test in Safari specifically. Safari has stricter font security policies than Chrome or Firefox and will sometimes block fonts that load fine elsewhere. Including multiple file formats (.woff2, .woff, .ttf) and a fallback font in your CSS helps.

If you uploaded via the native uploader and the font still isn't showing up where you want it, check whether your custom CSS is overriding it with a different font-family declaration on the same element.

I have some new resources that I built for designers who want to go further:

Custom Codey: The AI assistant trained on Squarespace. Writes code that works, knows your selectors, doesn't hallucinate. $30 lifetime access. customcodey.com

Beyond the Basics: My on-demand course for designers who want to master Squarespace customization in the age of AI. Five modules covering how Squarespace really works, the CSS that still matters, vibe coding (using AI to write your code), JavaScript for designers, and a complete customization workflow you can use on every project. Custom Codey is included. insidethesquare.co/beyond

Claude Club: The community for designers using AI to build smarter Squarespace sites. Live calls, prompt libraries, and the in-the-weeds technical conversations that don't happen in Facebook groups.
claude-club.com