Home / Blog

Test Storyline Web Object Content Locally with One Right-Click (Windows)

By Nathan Stoker · May 17, 2026 · 7 min read

Test Storyline Web Object Content Locally with One Right-Click (Windows)

You've built an HTML widget for a Storyline web object or a Rise code block. Maybe it's a 3D game, an interactive chart, a chat simulator, or a custom quiz. Now you need to know if it actually works before you wrap it in an authoring tool. Double-clicking the index.html opens it in a browser, but half the assets fail to load, fonts don't render, fetch calls die, and nothing behaves like it will once it's inside Storyline.

The fix is to test Storyline web object content locally on an actual HTTP server. The problem is that spinning up python -m http.server or npx serve every time you want to check a tiny change is friction you don't need. So I built a tiny Windows toolkit that adds a right-click "Open on Local Server" option to any HTML file. One click, your widget runs on localhost, and you can iterate without ever opening a terminal.

This is the companion post I promised in my 3D game in Storyline tutorial, where this exact workflow lets you change a config value, save, and refresh in seconds instead of round-tripping through Storyline every time.

Why Web Object Content Breaks When You Double-Click It

A Storyline web object is just a folder of HTML, CSS, JavaScript, and assets that gets dropped into the published course at runtime. While you're building that folder, you need to test it like a real web page, not a local file. Browsers treat file:// very differently from http://, and a lot of what your widget probably depends on gets blocked the moment you open the HTML directly.

The same-origin policy is the main culprit. From a file:// URL, the browser refuses most cross-origin requests, which means anything you load with fetch(), XMLHttpRequest, or even some <script> and <img> tags can silently fail.

In practice, double-clicking your web object's index.html usually means:

  • GLB models, JSON data, and audio files refuse to load

  • Web fonts and CSS @import references fail

  • ES modules and import statements throw CORS errors

  • fetch() calls die with "Cross origin requests are only supported for HTTP"

  • Anything pulling from a subfolder behaves unpredictably

Once your files are served from http://localhost, all of that works exactly the way it will inside Storyline or Rise. The browser stops blocking, assets resolve, and what you see locally matches what your learners will see in the published course.

What's Inside the Toolkit

The kit is four small files. No installer, no dependencies beyond what Windows already has.

File 1: open-local-server.ps1

The actual server. It's a PowerShell script that uses the built-in System.Net.HttpListener class to spin up an HTTP server in the folder of whatever HTML file you right-clicked. It tries port 8080 first, and if that's taken, it grabs any free port the OS gives it. Then it launches your default browser at the right URL and serves any file the browser requests.

File 2: open-local-server.vbs

A tiny VBScript wrapper. Its only job is to launch the PowerShell script without flashing a console window every time you use the menu. If you skipped this file and called PowerShell directly from the registry, you'd see a black terminal pop up for half a second every time. The VBS wrapper makes the whole thing silent.

File 3: add-local-server.reg

The registry file that adds the right-click context menu entry. It tells Windows: "When the user right-clicks an HTML file, show an option labeled 'Open on Local Server,' and when they click it, run the VBS wrapper with the file path as an argument."

File 4: remove-local-server.reg

The undo button. Double-click this and the context menu entry is gone. Nothing else on your system is touched.

How to Install the Local Server Toolkit

Setup is a one-time thing. About two minutes if you're being slow.

Step 1: Save the Files Somewhere Stable

Create a folder you won't move or rename. I use C:\Users\<yourname>\tools\local-server. Save all four files there. The path matters because the registry entry hardcodes it, so pick a location you're comfortable with long-term.

Step 2: Update the Hardcoded Paths

Open open-local-server.vbs in a text editor. You'll see this line:

command = "powershell -ExecutionPolicy Bypass -File ""C:\Users\nates\tools\local-server\open-local-server.ps1"" """ & WScript.Arguments(0) & """"

Change C:\Users\nates\tools\local-server\ to wherever you saved the files.

Then open add-local-server.reg and update the path there too:

@="wscript \"C:\\Users\\nates\\tools\\local-server\\open-local-server.vbs\" \"%1\""

Note the double backslashes. Registry files require them. Save both files.

Step 3: Install the Right-Click Menu

Double-click add-local-server.reg. Windows will warn you that you're about to modify the registry. Click Yes. You'll get a confirmation that the keys were added.

That's it. The menu entry is live.

Step 4: Test It

Find any HTML file. Right-click it. You should see "Open on Local Server" in the context menu, probably tucked under "Show more options" on Windows 11. Click it. Your default browser should open to http://localhost:8080/<filename>.html (or a different port if 8080 was busy), and your file should load over HTTP.

If you're testing a web object you're building, navigate to that folder, right-click the index.html, and click the new menu item. The widget should load and behave exactly as it will once it's inside Storyline.

How the PowerShell Server Actually Works

You don't need to understand the script to use the toolkit, but here's the short version. The PowerShell script is about 40 lines and uses the System.Net.HttpListener class that's built into .NET. It tries port 8080 first, and if that port is busy, it asks the OS for any free port so multiple previews can run side by side without colliding.

Once a port is locked in, the script starts the listener on http://localhost, splits your file path into a directory and a filename, and hands off the URL to your default browser. From that point on, it sits in a loop waiting for HTTP requests. Each request gets matched against a file in the served folder, read as raw bytes, and written back to the browser. Missing files return a 404.

There's no MIME-type magic, no caching headers, and no fancy features. The browser figures out content types from the file extension, which works fine for everything a web object needs. The listener only binds to the loopback address, so this server is only reachable from your own machine, never your network.

How to Test Storyline Web Object Content Locally in Your Workflow

Here's where it pays off. The typical iteration cycle without this tool looks like:

  1. Make a change to your web object HTML

  2. Save

  3. Open Storyline, update the web object, publish for Web

  4. Wait for publish

  5. Open the published output and dig to your slide

  6. Test

Or for Rise:

  1. Make a change to your code block HTML

  2. Open Rise, paste the new code into the code block

  3. Preview the lesson

  4. Test

With the local server toolkit:

  1. Make a change

  2. Right-click index.html, click "Open on Local Server"

  3. Test

You're testing the exact same file Storyline or Rise will eventually run, just without the authoring tool in the middle. Once it works on localhost, you can be confident it'll work as a web object or in a Rise code block.

It's especially valuable for anything that uses fetch-based asset loading, ES modules, GLB files for 3D content, or external JSON. None of those work from file://, so without a local server you literally can't test them outside the authoring tool.

Closing the Server

The PowerShell process keeps running until you close the browser tab and stop the listener. The cleanest way to shut it down is to close the browser tab, then open Task Manager and end the powershell.exe process if it's still hanging around. You can also just leave it running. Each preview spins up its own instance on its own port, so they don't conflict.

Key Takeaways

Being able to test Storyline web object content locally with a single right-click closes the feedback loop on building custom HTML widgets. You can stop guessing whether something will work once it's wrapped in an authoring tool and just see it run.

A few things worth remembering:

  • The toolkit only touches one registry key under HKEY_CLASSES_ROOT\SystemFileAssociations\.html. The remove file undoes it cleanly.

  • It only works on Windows, since it relies on PowerShell and the Registry.

  • It serves the entire folder, not just the file you clicked, so relative paths to images, scripts, and assets all resolve normally.

  • If you want this to work with other file extensions (like .htm), duplicate the registry entry and swap .html for the extension you want.

If you build something interesting on top of this, or improve the PowerShell script with proper MIME types or live reload, I'd love to see it. Share it in the Articulate Community and tag me. And if this saves you ten minutes today, it'll save you hours over the course of a project.

Now go right-click some HTML.