Most widget tools give you exactly one way to embed: an <iframe>. Widget Storm gives you three — and the reason there are three, not one, is the same reason none of them is an iframe. Widget Storm delivers widgets into your page; it does not seal them in a box. Here are the three delivery paths, from the deepest integration to the most universal, so you can pick the one that fits your stack.

The idea underneath all three

A Widget Storm widget is self-contained: its PHP, CSS, and JavaScript travel with it. When you embed one, you are not pointing at someone else's page — you are receiving the widget's own code and rendering it as part of yours. That is why it can inherit your layout, size to your content, and count toward your document. The three ways below are simply three ways to receive that delivery.

Way 1 — Server-side PHP: $wg->get() (the original, and the most powerful)

If your site runs on PHP, this is the deepest integration Widget Storm offers — and the one it was built on since 2008. You install your personal client once, then a single call renders the widget server-side, straight into your page's HTML.

One-time setup: download your personal wgclient.php and wghandler.php from the Station (they carry your encrypted key), and drop them on your webserver.

Then embed — three interchangeable forms:

<?php include "wgclient.php";
$wg->get("basic", "WidgetStormSystem", $params, "php"); ?>

<link rel="stylesheet" href="wgclient.php?wgname=basic&wgauthor=WidgetStormSystem&wgmode=css&wgparams=...">
<script src="wgclient.php?wgname=basic&wgauthor=WidgetStormSystem&wgmode=js&wgparams=..."></script>

Why it is the most powerful path:

• Truly native, server-rendered. The widget's markup is part of the HTML your server sends — so it is visible to search engines and screen readers as page content, not as a separate frame.
• Local cache, no round-trip. On first fetch the widget is stored in your own CodeVault (wgbuilds/); after that it renders locally, without a network hop per request.
• Composable. Widgets can nest other widgets, and the PHP-in-CSS/JS bridge lets a widget scope its own styles and scripts per instance.
• Encrypted delivery. The wghandler moves widget code encrypted (AES-256-CBC, or RIJNDAEL-256 for existing accounts).

The trade-off, stated plainly: this path needs a PHP server and a one-time client install. If you have that, nothing integrates deeper.

Way 2 — One script tag: the native loader

No PHP server? You still get native rendering — through a single script tag that injects the widget into your page's DOM wherever the tag sits:

<script src="https://widget-storm.de/wgembed.php?w=basic&a=WidgetStormSystem"></script>

That is the whole integration. It works on a static site, a CMS, a landing-page builder — anywhere you can paste a <script> tag. The loader is plain JavaScript, pulls the widget cross-origin (script loading needs no CORS), and mounts it in place — no iframe, no box, no fixed height. It serves open widgets (public by definition); nothing private ever reaches the browser.

This is the universal path: less setup than Way 1, available everywhere, at the cost of the server-side niceties (local cache, nesting, PHP params) that the $wg->get() path gives a PHP host.

Way 3 — "But everyone else uses an iframe."

They do — and Widget Storm deliberately does not. An iframe renders the widget on the provider's page and drops it into a sealed rectangle on yours. That buys isolation, but it costs you everything that makes an embed feel like part of the page:

• a fixed box that fights responsive height,
• no inheritance of your fonts, colours, or spacing,
• content that is not part of your document (weaker for SEO and accessibility),
• and no native DOM interaction.

For a widget whose entire purpose is to become part of your page, an iframe is a step down in capability, not up. Widget Storm's model is deliver-and-render; isolation is the one thing it intentionally leaves out.

Which one should you use?

There is no single right answer — there is the right answer for your stack. A PHP shop gets the most out of $wg->get(); a static site gets a genuinely native widget from one script tag. Either way, the widget ends up as part of your page, not boxed off from it.

Where Widget Storm sits

Widget Storm has delivered embeddable web components since 2008, and every path above reflects the same choice: render the widget into your page, don't isolate it. One script tag if you want the quick universal route; the $wg->get() server-side path if you want the deepest one; never an iframe.

PHP integration guide →
Browse the widgets →

FAQ

How do I embed a Widget Storm widget without an iframe?
Two native ways: on a PHP server, include your wgclient.php and call $wg->get("name", "author", $params, "php") to render it server-side; on any other site, add one <script src="…/wgembed.php?w=NAME&a=AUTHOR"> tag that injects the widget into your DOM. Neither uses an iframe.

What is the difference between the PHP path and the script loader?
The PHP path ($wg->get()) renders the widget server-side into your HTML, caches it locally, and supports nesting and PHP parameters — the deepest integration, for PHP hosts. The script loader works on any site with a single tag, rendering the widget natively client-side, for open widgets.

Does Widget Storm use iframes?
No. Widget Storm delivers a widget's own code and renders it natively into your page. An iframe would isolate it in a fixed box — the opposite of that model.