ORTB Creative Renderer

A free, in-browser tool for ad-tech engineers, QA, and ad ops. Paste a raw OpenRTB BidResponse, and the renderer extracts the adm, resolves any VAST wrappers, applies macro substitution, and paints the creative in a sandboxed iframe — no data ever leaves your laptop.

What it does

The ORTB Creative Renderer takes a complete OpenRTB bid response — exactly the JSON shape your DSP returns or your SSP forwards — and turns the embedded creative markup into something you can actually look at. You no longer have to copy the adm field into a scratch HTML file, decode entity-escaped characters, hand-substitute macros, and follow VAST wrappers in a browser tab. All of that happens inside the tool, in a sandboxed frame that simulates how a publisher page would render the markup.

The renderer understands three creative families that cover virtually every programmatic format in production: HTML banners, VAST 2/3/4 video tags (with wrapper redirects), and OpenRTB native (assets per the IAB native spec). The tool auto-detects which family you pasted.

Who it's for

Three audiences spend their days inside BidResponse payloads, and the renderer is built for all of them.

• Ad-tech engineers at DSPs, SSPs, and bidders. When a creative breaks in production, the question is "is the markup broken, or is the integration broken?" Rendering the raw adm in isolation answers that in seconds.
• QA and ad ops validating partner integrations. Before turning on a new demand source, sample a handful of bid responses and confirm the creatives load, the trackers fire to the right hosts, and the click URLs land where they should.
• Publishers and SSP support investigating buyer complaints. Pull a raw bid response from logs, paste it in, see exactly which pixels are wired up and in which order.

When to use it

There are a few moments in any ad-tech workflow when the renderer earns its keep.

• Debugging DSP creatives. Your creative QA team forwards a bid response that "doesn't render on Publisher X." Paste it in. If it renders here, the problem is downstream — publisher CSP, SafeFrame quirks, or a wrapper script. If it does not render here either, the markup itself is wrong.
• Validating SSP responses. Before you ship a new SSP adapter to prebid or a server-side bidder, you want to confirm that the adm you forward is structurally valid for every format you support. Drop one bid response per format through the tool.
• Integration testing. When you stub out a partner during development, the renderer is a quick way to confirm your fixture data is realistic — that a fake VAST you generated actually resolves and plays.
• Vendor identification. Sometimes you receive a creative and want to know who served it without touching the trackers. The tool surfaces vendor hints from script URLs, macro patterns, and known beacon hosts.
• Pre-launch checks for a new endpoint. Anytime you stand up a bidder, a wrapper, or a creative transformation pipeline, the renderer is a smoke test you can rerun by hand on real traffic samples.

How it works

The flow is intentionally short. You paste, the tool reads, the iframe renders. There is no upload, no account, no server-side processing.

1. Paste the bid response. The full JSON from your DSP or SSP — seatbid[].bid[].adm is what the renderer is looking for, but you do not need to extract it yourself. You can also paste a single bid object, or just the raw adm string.
2. ADM extraction. The parser walks the response, picks the first adm it finds (or lets you choose if there are several), and decodes any HTML or JSON entity escaping that the response transport may have introduced.
3. Format detection. The decoded string is sniffed: starts with <VAST or contains an <Ad element → VAST. Parses as JSON with a native or assets key → native. Anything else → HTML banner.
4. Macro substitution. Common OpenRTB and vendor macros — ${AUCTION_PRICE}, ${AUCTION_ID}, ${CACHEBUSTER}, [timestamp], and many more — are replaced with sensible test values so trackers actually fire when the creative loads.
5. Sandboxed iframe rendering. The processed creative is dropped into an iframe with sandbox attributes that approximate a typical publisher SafeFrame — scripts allowed, top navigation blocked, same-origin restricted.
6. VAST chain following. For VAST, the renderer parses the XML, finds VASTAdTagURI in any wrapper, and walks the chain. CORS-blocked wrapper URLs are fetched through a configurable proxy when available; otherwise the chain stops gracefully and reports where.
7. Vendor detection. Tracker hosts, script names, and macro shapes are matched against a built-in list of known ad-tech vendors so you immediately see which DSPs, verification partners, or attribution vendors are involved in the impression.

Supported formats

Common use cases

The everyday work the renderer makes faster.

• Debug a broken creative. Reproduce the exact rendering pipeline a publisher uses, in isolation, so you can tell whether the bug is in the markup or in the page that hosts it.
• Verify macro substitution. Confirm that your auction-price encryption, your cachebuster, and your custom vendor macros all get replaced where you expect — and not somewhere you don't.
• Inspect tracker URLs. See every impression pixel, viewability beacon, and click tracker the creative would fire, grouped by event and vendor, before it touches a real impression.
• Reproduce a discrepancy. Buyer says your nurl fires twice. Paste the bid, watch the trackers, prove it (or prove it doesn't).
• Audit third-party scripts. The renderer surfaces every external script the creative loads. Useful for security review and for verifying that ads.txt / sellers.json claims line up with reality.

Frequently asked questions

Does it work with VAST wrappers?

Yes. The renderer parses the wrapper, extracts VASTAdTagURI, fetches the next tag in the chain, and repeats until it hits an InLine ad or a redirect cap. Each hop is logged so you can see exactly where the chain went and how long each fetch took.

What about CORS-protected wrappers?

Many VAST wrapper hosts do not return CORS headers, so the browser refuses to read the response body. The renderer can be configured to use a public CORS proxy (or one you host yourself) so the chain still resolves. If no proxy is configured and a hop fails CORS, the tool stops and shows you which URL it could not reach, so you can debug from there.

Is my creative data sent to a server?

No. Parsing, decoding, macro substitution, and rendering all happen in your browser. The only network requests the tool makes are the ones the creative itself triggers — impression pixels, click trackers, VAST hops, scripts loaded by the markup. Your raw adm, the JSON you paste, and the rendered output never leave your machine.

Can it render native ads?

Yes. The renderer parses OpenRTB native 1.1 and 1.2 response payloads, matches assets by id against a generic native layout (title, body, main image, icon, CTA button), and wires up the impression and click trackers. You can use it to confirm a buyer is returning every required asset before promoting their seat to live traffic.

Does it support OMID and MRAID?

OMID and MRAID expect a host environment that the open web does not natively provide — they live inside in-app SDKs and managed SafeFrame implementations. The renderer does not stub the full OMID API, but it will load OMID-bearing scripts without crashing, log calls the creative makes to window.omid3p, and surface MRAID host detection so you can see what the creative would try to do.

What OpenRTB versions does it understand?

Any OpenRTB 2.x bid response. The renderer is not strict about schema validation — it walks the JSON tree looking for adm, nurl, burl, w, h, cat, adomain, and a handful of other fields, and is tolerant of vendor extensions you may have under ext.

Will trackers actually fire when I render?

Yes, by design. The whole point of the tool is to reproduce what a publisher page would do. Impression pixels, viewability beacons, third-party scripts, and click trackers all hit their real endpoints. Use the tool with the same care you would use any creative debugging environment.

Can I render a creative without firing trackers?

Disable network requests at the browser level (DevTools "offline" mode or a request-blocking extension) before rendering. The creative still loads from the adm string itself; only outbound calls are suppressed. The tool also has a "dry-run" mode that strips known beacon URLs before rendering.

Why is the rendered creative a different size than I expected?

The iframe sizes itself from the bid's w/h when present. If they are missing, the renderer scans the markup for common sizing hints — <meta> tags, inline width/height attributes, CSS — and falls back to a reasonable default. You can also pin the iframe to any size via the size selector.

Privacy

Everything in the ORTB Creative Renderer runs client-side in your browser. There is no upload step, no telemetry that captures your adm, and no server-side log of the bid responses you paste. The only requests the page itself makes are the static assets that load the tool. Once the tool is in the browser, any further network activity comes from the creative you render, exactly as it would on a real publisher page. We built it that way on purpose, because nobody wants to email a bid response to a SaaS just to look at it.

Related tools

• JSON Beautifier and Validator — clean up the bid response before pasting it
• URL Decoder and Encoder — decode tracker URLs and click-through parameters
• Online Diff Tool — compare two bid responses side-by-side

Related reading

• What is OpenRTB? A complete guide for ad-tech developers
• Creative debugging in programmatic: a practical workflow