Pasted code on Wix, Squarespace and Webflow: where each builder lets it run and where it breaks

Where each builder lets code run

Webflow has three places: site-wide head and footer code, the same two locations on a single page, and a code embed element placed in the page. Each location holds up to 50,000 characters.

Squarespace has code injection: a header field that adds code to the head of every page and a footer field that adds code before the closing body tag, plus page-level injection and code blocks. Code injection is available on the Core, Plus and Advanced plans and some legacy plans. Checkout pages do not support code at all; the order confirmation page does.

Wix has two separate routes. Custom Code in settings adds a snippet to the head or body, on all or selected pages. The HTML embed element places code inside the page content as an iFrame. They obey different rules.

• Write down which of these places holds your snippet.
• Check the plan limit for that place in your own builder.
• Keep the original snippet text before changing anything.

Why a valid snippet still breaks the page

A Wix HTML embed is an iFrame. Embedded content does not become responsive even if it was built that way, fixed pixel sizes such as a width of 560 can crop it on a small screen, plain http content will not display, and the code is not placed in the page's own structure but in a frame. Some sites also forbid being shown inside another site, and no builder can bypass that.

Wix Custom Code has its own trap: Google Analytics, Google Tag Manager and Facebook and TikTok pixels do not work through it and must use the marketing integrations. In December 2025 Wix added frontend security measures, so a snippet that used to work can be blocked until its provider updates it. On Squarespace, the help article warns that custom code can break a site's look or behaviour, especially on mobile.

• Replace fixed pixel sizes with percentages inside a Wix embed.
• Use https addresses everywhere.
• Ask the widget's vendor whether it allows embedding in a frame.

A safe first investigation

Do not delete things. Make a list of every snippet on the page and the date each was added, then test with them switched off one at a time. Wix describes this approach directly: turn each snippet's toggle off in turn and test the site after each change. Squarespace suggests removing all custom code temporarily, saving it in a text file, and reloading.

Open the browser's developer console on the broken page and record any errors, then repeat after each change. The goal is to find the one snippet whose presence or placement changes the console. That tells you whether the fix is to move it, replace it with the builder's own integration, or ask the vendor.

• Record the console errors before changing anything.
• Test on a preview where the builder offers one; Wix says Custom Code needs a published site with a connected domain, so it cannot be tried on an unpublished copy.
• Restore the original text if a change makes no difference.

Who supports what, what does not fit, and acceptance

Wix says it does not support technical issues with third-party snippets, and Squarespace says its support team cannot help add or troubleshoot custom code. That leaves the owner with the vendor and the builder's documented rules, which is the gap this job fills. A widget that the vendor blocks from being framed, or code needed on Squarespace checkout pages, cannot be fixed by anyone.

The fixed-scope fix of one snippet or widget is priced at £125 as an untested proposal and paid only after you sign off. It is accepted when the named pages show no new console errors, a widget works at desktop and phone width, and a tracking tag sends exactly one page view per load.