Custom code in Webflow, and where it belongs

I write custom code on Webflow sites for a living, so the useful thing I can offer is not permission. It is the test I apply before writing any.

The field has a ceiling, and it is closer than you think

A Webflow custom code field holds 50,000 characters. Source: Custom code in head and body tags

That is generous for a tracking snippet and nothing at all for an application. What makes it bind sooner than the number suggests is that the field has no minification step, no bundling and no imports. Everything is inline, uncompressed, exactly as typed. A library pasted in rather than linked eats the budget in one go.

There is also no version control. No history, no blame, no diff, no way to see what changed between Tuesday and the outage on Wednesday. The field is the only copy, and the only record of it is whatever somebody remembers.

Site-wide against page-level

The default instinct is to put everything site-wide, because then it is everywhere and nobody has to think about it again. That instinct is why so many Webflow sites load a booking widget on the privacy policy.

Site-wide earns its place for things that genuinely apply everywhere: the analytics loader, consent, a font preconnect, anything that has to run before the first paint on any page.

Page-level is correct for everything else, and "everything else" is most of it. A calculator on the pricing page, a map on contact, a third-party embed on one landing page. Putting those site-wide costs every other page the download and the parse, which is the most common self-inflicted performance problem I find.

The test is simple: if the code would do nothing on a page, it should not be on that page.

When it belongs somewhere else entirely

Some code should not be in the field at all, and the line is clearer than people expect.

The secret one is absolute rather than a preference. There is no environment in a Webflow code field: anything in it is in the page source, visible to anyone who opens the inspector. An integration that authenticates has to run somewhere else, with the page calling out to it. That is why connecting Salesforce is a different shape of job from adding an analytics script.

Keeping it reviewable

The practice that costs almost nothing and saves the most: keep the real copy of anything non-trivial in a repository, and paste the built version into the field.

You get a diff, a history and somewhere to put a comment explaining why the thing exists. When somebody asks in eighteen months why the site is doing something strange on one page, there is an answer that does not depend on memory.

Two smaller habits worth the same trouble. Put a comment at the top of every field saying what the code is for and who to ask, because the person who inherits it will otherwise delete it or be afraid to. And when something is genuinely temporary, write the date it can be removed into the comment. Nothing on a website is as permanent as a temporary script with no expiry on it.

The question worth asking first

Before any of this, there is a cheaper question: does Webflow already do it?

A surprising amount of the custom code I find on sites is doing something the platform shipped since it was written. Interactions that predate the current ones. A script animating on scroll. A hand-rolled accordion. Each of those was correct when it was added and is now a maintenance cost with no benefit.

That is the honest version of "we have too much custom code." It is usually not too much. It is old, and nobody has read it since.

Limits checked September 2026. They are Webflow's to change, so treat the number as the shape of the constraint rather than a specification.