How do I test an ad tag without uploading it to a server?

Open Alvseike's Code Playground, paste the ad tag into the HTML panel, set the container dimensions, and watch the live preview. Everything runs in your browser, so the tag — including any IDs or tokens it contains — never leaves your device.

Why does my ad tag show a blank space in the preview?

The most common cause is a missing container size. Ad tags usually need an explicit width and height on the wrapping element, otherwise they collapse to zero. Check the browser console for mixed-content or CORS errors next.

Can I test an HTML5 ad in a browser sandbox?

Yes. Paste the HTML5 ad's markup, CSS and JavaScript into Code Playground and it renders in the live preview. This lets you check animation timing, click-through links and fallback behaviour before the creative goes to your ad server.

Is a live HTML preview as accurate as testing on a real page?

For the tag's own code, yes. The sandbox runs a real browser engine, so JavaScript, CSS and iframes behave normally. It cannot simulate your ad server's targeting or your site's consent platform, so use staging for those.

Does Code Playground have a file-size limit for HTML files?

There are no file-size caps, because nothing is uploaded — the file is opened from your machine and processed in the page. Code Playground takes one file at a time, so load a single HTML file per test.

How to Test an Ad Tag in an HTML Sandbox

You can test an ad tag in an HTML sandbox by pasting the tag's HTML, CSS and JavaScript into a live editor and watching it render as you type. Code Playground is a browser-based HTML, CSS and JS playground that does exactly that — no upload, no server round-trip, and your code never leaves your device.

Ad tags are notoriously fiddly. A single missing async attribute or a malformed src URL can leave you staring at a blank iframe. A live HTML preview removes the guesswork by showing you the rendered result immediately, so you can iterate on the tag until it fires correctly.

What is an HTML sandbox and why use one for ad tags?

An HTML sandbox is a self-contained environment where you can write HTML, CSS and JavaScript and see the combined output in a live preview pane. Unlike a full development setup, there is nothing to install and no build step. You open the page, type, and the preview updates.

For ad tags, this matters because ad tags are not plain HTML. They are usually a mix of:

A <script> block that loads an external library
An <ins> or <div> element that the library targets
Inline CSS that controls the ad slot's dimensions
A fallback image or text link for when the ad does not fill

Testing all four pieces together in a real browser context is the only way to know whether the tag will work on a live page. A sandbox gives you that context without touching your production site.

How to test an ad tag in an HTML sandbox: step by step

Open Code Playground. You will see a drop zone labelled 'Drag & drop or browse' under the line 'Processed locally — your files never leave your device'. The editor takes one file at a time, so if you have an existing HTML file with your ad tag, drag it onto the drop zone to load it. If you are starting from scratch, just start typing in the editor.
Paste your ad tag into the HTML panel. Copy the tag exactly as your ad server gave it to you. Do not reformat it. If the tag includes a <script> tag, paste that too. The playground runs JavaScript, so the tag will execute.
Set the container dimensions. Most ad tags expect a specific slot size — 300x250, 728x90, 300x600. Add a wrapping <div> with explicit width and height, or set the dimensions on the ad element itself. Without this, the ad may collapse to zero height and appear invisible.
Watch the live preview. As you type, the preview pane updates. If the ad renders, you will see it. If it does not, you will see either a blank space or a console error. This immediate feedback is the core advantage of a live HTML preview over editing a file and refreshing a browser tab.
Open the browser console if nothing appears. Right-click the preview area and choose 'Inspect', then switch to the Console tab. Common errors include blocked mixed content (an http:// tag on an https:// page), a missing async attribute on a third-party script, or a CORS policy rejection.
Test the fallback. Temporarily break the tag's src URL — change one character — and reload. If your fallback image or text link appears, it works. If you see nothing, your fallback is not wired correctly.
Adjust the CSS and re-test. Use the CSS panel to add display: block, margin: 0 auto, or any layout rules your page needs. The preview updates instantly, so you can see the effect of each change without a full page reload.
Copy the working code back to your site. Once the tag renders correctly in the sandbox, you know the tag itself is valid. Any remaining issues on your live site are almost certainly caused by the surrounding page — a conflicting CSS rule, a content security policy, or a script that loads after your tag.

Why local, in-browser processing beats upload-based online tools

Most online HTML editors work by sending your code to a server, rendering it there, and sending a screenshot or an iframe back. That model has three problems for ad tag testing.

Privacy. Ad tags often contain placement IDs, site IDs, and sometimes authentication tokens. Uploading them to a third-party server means those values leave your machine. Code Playground runs entirely in your browser — the file is opened from your own machine and the work happens in the page. Nothing is uploaded.

Speed. A local preview updates as you type. A server-rendered preview waits for a network round-trip on every change. When you are debugging a tag that fails silently, that delay adds up fast.

No file-size caps. Because there is no upload, there is no server-side limit on how large your HTML file can be. A page with a dozen ad slots and a large inline stylesheet is fine.

There is one practical trade-off: because the sandbox runs locally, it cannot simulate your production ad server's targeting, frequency capping, or geo rules. It tests the tag's code, not your ad server's logic. That is the right scope for a sandbox.

Common mistakes when testing ad tags

Forgetting the container size. A tag with no explicit width and height often renders at 0x0. Always set dimensions on the wrapping element.
Testing on file:// instead of a real origin. Some ad libraries behave differently when the page origin is null. If a tag works in a local file but not in the sandbox, check whether the library requires a real origin.
Ignoring mixed-content warnings. An http:// ad tag on an https:// page is blocked by the browser before the tag ever runs. The console will tell you, but only if you look.
Editing the tag before testing it. Paste it verbatim first. If it works, then modify. If you reformat first and it fails, you will not know which change broke it.
Assuming a blank preview means a broken tag. Some tags render asynchronously and take a second or two. Wait before you start debugging.

Pro tips for a smoother HTML sandbox workflow

Keep a scratch HTML file with your most-used ad tag dimensions already set up as empty containers. Drag it onto the drop zone, paste in the tag you are testing, and you skip the sizing step every time.

If you are testing a tag that will sit next to other page content, add a few paragraphs of placeholder text above and below it. Ad libraries sometimes measure the viewport to decide whether to render, and a page with nothing but an ad can behave differently from a real article page.

When you have a tag working, screenshot the rendered result and drop it into Mockup Generator to see how the ad will look inside a phone, browser or laptop frame. It is a fast way to sanity-check the creative before it goes live.

If your ad tag is part of a larger campaign that also needs social assets, Social Pack Exporter exports one design to every social size in a single pack. And if you are testing audio ad creative alongside display, Podcast Artwork Pack turns one square of cover art into every size Apple, Spotify and your host ask for.

When to use a sandbox and when to use staging

A sandbox is the right tool when you want to answer a narrow question: does this tag's code run correctly in a browser? It is fast, private, and gives you a clean environment with no other scripts interfering.

Staging is the right tool when you need to answer a broader question: does this tag work inside my actual page, with my actual CMS, my actual consent management platform, and my actual ad server? Those are different questions, and you should not try to answer the second one with a sandbox.

The efficient workflow is to use the sandbox first. Confirm the tag is syntactically valid and renders in isolation. Then move to staging to confirm it plays nicely with everything else. Debugging a tag that is broken in two places at once is far harder than debugging it in one place at a time.

Code Playground is free to use with no account, metered at 5 runs per day; a free account raises that to 15 a day, and a Pro plan unlocks unlimited daily use. A run is one export, however many files it contains. For ad tag testing, most people find the free daily allowance is plenty — you are iterating on one file, not exporting dozens.