Widget builder
Embed a Live Oniongate Status Badge: iframe, Script and Copy-Paste Snippet
Show a single onion market's oniongate reading on your own page. The badge reports the same reading you see on oniongate's board, so when a service goes down your page reflects it without you touching anything. Pick a format below, copy the snippet, and drop it where you want the badge to sit. The preview is static here, the embedded version updates from oniongate's own feed.
<a href="https://oniongate.live/status/torzon/">
<img src="https://oniongate.live/widget/badge/torzon.svg"
alt="torzon status on oniongate" height="28">
</a>
<iframe src="https://oniongate.live/widget/iframe/torzon"
title="torzon status on oniongate"
width="240" height="40" loading="lazy"
style="border:0"></iframe>
<div data-oniongate="torzon"></div>
<script src="/widget/embed.js"
async></script>
How each format behaves
Putting an oniongate badge on your page
- Choose the service you want to show and copy its snippet above.
- Paste it into your template where the badge should appear.
- Publish. The badge picks up the live oniongate reading on the next sweep.
- Nothing else to maintain. When oniongate records a change, your badge changes with it.
The snippet endpoints shown here are placeholders that go live when the feed is attached. Every embed links back to the full status page so a reader can see the mirrors and the timestamp for themselves.
Why the widget shows the same word oniongate does
A badge that read Online when the board itself read Unknown would undermine the entire point of embedding it — the widget pulls from the same probe result as the full status page, not a separate cached copy, so a reader on your site sees exactly what a reader on oniongate would see at that moment. There is no separate "friendlier" reading reserved for embeds.
What the widget does not do
It does not track visitors to your page, set a cookie, or phone home with anything beyond the minimum request needed to fetch the current reading. It does not run any script beyond rendering the badge and linking back to the full status page. If your own site has a strict content security policy, point it at this same origin and nothing else.
Choosing between oniongate's three embed formats
Badge: the smallest, least particular option
A single small image, sized to sit inline with text or in a sidebar. It updates on a normal image refresh cycle rather than continuously, which makes it the lightest option for a page that just wants a reachability indicator without any JavaScript at all. Choose this when you want a status marker with zero script footprint on your own page.
Iframe: a live embedded status card
A small embedded document that mirrors a slice of the real status page, refreshing on its own without reloading your page around it. It costs one extra HTTP request and a small amount of layout space, in exchange for a reading that updates without a visitor needing to reload your page.
Script: for a page that wants to style the badge itself
The script tag renders into a target element you control and hand-styles it to match your own page's design, using your CSS rather than oniongate's badge styling. This is the option for a site that wants the reading itself but not the visual presentation that comes with the badge or iframe formats.
When the widget is not the right fit
The widget shows one service's reading at a glance; it is not a replacement for the fuller history a visitor gets from the actual status page. If your audience needs the 24h, 7d and 30d breakdown, or the full onion address to verify, link to the status page directly rather than relying on the badge alone to carry that weight — the badge is a pointer, not a substitute for the page it points to.
Keeping an embedded OnionGate badge honest over time
An embedded badge is a small commitment: it tells your visitors a reading is live, and that only stays true if the embed keeps working the way it did on the day you added it.
The badge fetches live, it does not bake in a snapshot
Every OnionGate embed format pulls its reading at page-load time rather than shipping a hard-coded value from whenever you copied the snippet. A page that embeds the badge once and is never touched again still shows a current reading years later, as long as the embed code itself stays in place and OnionGate keeps serving that endpoint.
What happens if OnionGate is unreachable when your page loads
If a visitor's request to OnionGate's badge endpoint fails or times out, the widget is built to fail toward Unknown rather than silently showing a stale cached state as if it were current. A missing or Unknown badge on your page is more honest than a badge frozen on the last successful reading from an earlier visit.
Why OnionGate does not ask you to self-host the badge assets
Serving the badge from OnionGate directly, rather than handing out static assets for you to host yourself, is what keeps the reading live instead of freezing it at embed time. The trade-off is a dependency on OnionGate's own uptime for the badge itself — reasonable for a status indicator, worth knowing if your page has stricter zero-dependency requirements.
Which onion markets an oniongate badge can show
Any of the seven markets on oniongate's roster can be embedded with the same three snippet formats above — swap the market slug in the code and the badge, iframe or script points at that service instead. The set is the same seven oniongate probes everywhere else on this site: torzon, mars, wethenorth, nexus, vortex, omega and drughub.
Why the embeddable list matches the tracked list exactly
oniongate does not maintain a separate, wider catalog of embeddable slugs beyond what it actually probes. A badge can only ever be as honest as the measurement behind it, so the widget deliberately refuses to generate a snippet for a market oniongate has not independently verified into its signed directory and does not actively check on the probe loop described on the methodology page.
Adding a badge for a market not yet on oniongate's roster
If a market you want to embed is not on the list, the badge builder cannot produce a meaningful snippet for it, because oniongate has no probe result to serve at that endpoint. The market would need to first go through the same verification path every currently tracked service went through — a signed address, added to the roster, then probed on the regular cadence — before an embeddable oniongate reading exists for it at all. That order is not negotiable, even for a widely requested market, because a badge is only as trustworthy as the probe standing behind it.
Where an embedded oniongate badge is actually useful
A status badge earns its place on someone else's page only where a stale or wrong reading about an onion market would actually cost a reader something. A few real patterns show up repeatedly.
Darknet market directories and forums
A directory listing several darknet markets side by side is exactly the kind of page an oniongate badge was built for: instead of a directory operator manually updating "up" or "down" next to each onion market by hand, whenever they remember to, the badge pulls a live reading from the same Tor probe loop oniongate runs for its own board. A forum thread discussing a specific darknet market benefits the same way — a badge embedded once in an opening post stays current for the life of the thread, without anyone editing it after that market's status changes.
Tor-focused wikis and reference pages
A wiki page documenting a darknet market's mirrors and history is a natural home for a status badge, since the wiki's own text tends to go stale faster than a live Tor probe does. Embedding the badge next to the market's listed onion address keeps a reachability signal current even when nobody has edited the surrounding wiki text in months.
Where a badge is the wrong tool
A page that needs to show every onion market oniongate tracks at once should link to the live board directly rather than stacking seven separate badges — the homepage board already exists for that view, and seven independent badges over Tor reload seven times instead of once. An embedded badge earns its place on a page about one specific darknet market, not as a substitute for the fleet-wide board itself.
Why the badge always names the specific onion market
Every badge, iframe and script snippet carries the market slug baked into its endpoint — torzon, mars, vortex, and so on — rather than a generic "onion market status" placeholder that could quietly point at whichever market oniongate feels like serving that day. A reader glancing at an embedded badge on a Tor-focused page should see, at a glance, exactly which darknet market the reading describes, not a vague status pill that could belong to any market on the board.
Status widget: questions people ask
Does the widget cost anything to use?
No. The badge, iframe, and script embeds are free to use on any site, with no account or API key required.
Will the widget ever show a different reading than the live board?
No — it draws from the same probe result as the full status page and the homepage board. There is no separate, friendlier reading held back for embeds.
Can I embed more than one market's badge on the same page?
Yes. Repeat the snippet for each service you want to show, each pointing at its own market slug in the URL.
What happens to the badge if oniongate's own probe feed goes down?
It shows Unknown, exactly like every other reading on this site during a feed outage — never a stale cached "Online" left over from before the feed dropped.
A worked example: picking an oniongate embed format for three real situations
A static forum signature
Forum software strips most script tags for good reason, and a signature block is rarely rendered inside an environment you control end to end. The badge format is the right call here: it is a linked image, it degrades to a plain text link if the image itself is blocked, and it never asks the forum's own security policy to trust a third-party script. The tradeoff is that a signature badge only updates when the page is reloaded, which for a forum signature that gets re-rendered on every page view is not really a limitation at all.
A market comparison page you maintain yourself
If you are running your own page and want a status reading that updates without a visitor refreshing, script is the format built for that. It renders into a marker element you place, refreshes in place on the same sweep cadence the board itself uses, and does not require an iframe boundary. The cost is that you are running a small piece of third-party code on your own page, which is a reasonable trade only when you actually control that page and its content security policy.
A page where your own CSS keeps clashing with the badge
iframe exists for exactly this case. It carries its own styling inside its own document, so nothing your page's stylesheet does can accidentally recolor, resize, or break the embedded status reading. It also renders identically inside Tor Browser regardless of what theme or extension a visitor has active, which the script and badge formats cannot fully guarantee since they inherit more from the host page.
Troubleshooting an embedded oniongate badge, expanded
The badge shows unknown and will not move
Unknown is not a broken embed — it is oniongate's honest default when there is no fresh measurement to show, and an embedded badge inherits that default the same way the full status page does. Before assuming the embed is misconfigured, check the service's own status page directly; if it also reads unknown there, the badge is working exactly as designed and simply has nothing better to report yet.
The script format stopped updating after a redesign
The script embed looks for a specific marker element by its data attribute. A redesign that changes the surrounding markup without preserving that marker will leave the script with nothing to render into, and it fails silently rather than throwing a visible error onto your page. Reconfirming the marker element survived the redesign is the first thing to check.
The badge looks fine locally but breaks for Tor Browser visitors
This is almost always a content security policy issue rather than an oniongate problem: a host page's CSP can block the embed's request even when a regular browser without a strict CSP loads it without complaint. Checking the CSP header for a data or script-src exception covering the embed's own origin usually resolves it.