FlashVars Explained: How One Game File Became a Hundred Different Portal Skins
Play the same game on three different portals and the logo, the language, even the difficulty could all be different, despite every site loading the exact same swf file. A small embedding parameter is why.
A Flash game distributed to dozens of portals presented an odd technical problem: the file itself was one static binary, compiled once by the developer, yet every portal that hosted it wanted something slightly different from it. One site wanted its own logo on the splash screen instead of the developer's. Another wanted the game's text in a different language for its regional audience. A sponsor paying for exclusive placement wanted its branding shown only on its own domain and nowhere else. Recompiling a separate version of the swf for every portal that asked for a tweak was not realistic for a developer distributing to a hundred sites at once, so the format needed a way to pass information into an already-compiled file at the moment it loaded, without touching the file itself.
How the mechanism actually worked
The solution was a set of key-value pairs, called FlashVars, attached to the embed code a webpage used to load a swf file — either inside an <object> or <embed> HTML tag or appended to the loading URL itself. When the Flash Player initialized the movie, it read those key-value pairs and made them available to the ActionScript running inside, which could then branch its behavior accordingly: show a specific logo image if a "sponsor" variable matched a known ID, load a different text file if a "lang" variable was set to a particular language code, or unlock a harder starting difficulty if a "mode" variable equaled a specific value. None of this required a network request back to the developer; it was resolved entirely from information the hosting page supplied at load time, which meant it worked even for sites that mirrored a swf file locally rather than embedding it from the original source.
Why this mattered for portal syndication
This single mechanism is a large part of why the syndication economy covered in our piece on how one Flash game ended up on a hundred portals was viable at scale. A developer could compile one file, hand each portal a slightly different embed snippet with different FlashVars values, and let every portal's copy look locally branded without any additional development work. Ad networks used the same trick to pass an ad-zone identifier into a game so its in-game ad slot pulled inventory correctly for whichever portal was hosting it, tying directly into the banner and popunder economy we cover in our look at how free portals actually made money.
The security tradeoff nobody talked about much
Because FlashVars values came from the hosting page rather than from the developer's own server, a game that trusted them too readily could be manipulated by anyone controlling the embed code. A high-score submission variable, a difficulty flag, or an unlock condition passed in this way could sometimes be edited directly in a page's HTML before the game even loaded, letting a technically curious visitor start a game already unlocked or skip a paywall a sponsor had intended to enforce. Developers who cared about this built validation on their own server rather than trusting anything passed in through the embed, but plenty of smaller or rushed games did not bother, and browser extensions that let curious users inspect and edit embed parameters directly circulated informally among players who wanted to poke at exactly this weakness.
A pattern that outlived Flash itself
The specific mechanism died with the Flash Player, but the underlying idea did not. Modern web embeds, from video players to interactive widgets, still pass configuration into an otherwise-static piece of embedded content through URL parameters or data attributes on the hosting element, following essentially the same logic FlashVars established: one compiled asset, many contexts, resolved by whatever the embedding page chooses to declare. The HTML embed element's own documentation still describes this pattern today, even though the plugin content it was originally built to configure is long gone. Anyone who has ever changed a YouTube embed's autoplay behavior by editing a URL parameter has used a direct descendant of the same idea that let one Flash game file wear a hundred different portal skins.