JavaScript sandbox runner
Run JavaScript inside a browser Worker: console output is captured, the default 3-second timeout terminates the worker, errors and stack traces are shown, and network entry points such as fetch, XMLHttpRequest and importScripts are disabled.
Runs in your browserEvery computation happens in your browser — your data never leaves this device.
Code
Code runs in a separate Worker thread and the main thread never uses eval or new Function; on timeout the whole worker is terminated, so an infinite loop cannot freeze the page.
Result
Nothing yet — press “Run” and anything logged with console.log shows up here.
What this tool does
- Check a piece of JavaScript without opening a terminal or devtools: paste it in, press Run and read the result on the page.
- See how your code behaves in a restricted environment: fetch, XMLHttpRequest and importScripts are disabled in the sandbox, which quickly reveals logic that secretly depends on the network.
- Demo or teach with code that loops forever: the timeout terminates the worker, so the page keeps responding.
- Reproduce an error: the message and stack trace are shown inline instead of hidden in the browser console.
Example
Input
console.log('sum', [1, 2, 3, 4].reduce((total, value) => total + value, 0));Output
[log] sum 10 Status: Finished
Lines are appended in the order they arrive and objects are formatted as compact JSON (circular references become [Circular]). A timeout only terminates the worker — everything printed so far stays on screen.
Frequently asked questions
Where does the code run, and can it freeze the page?
In a separate Web Worker thread; the source is turned into a Blob and handed to the worker, and the main thread never uses eval or new Function. On timeout (3 seconds by default) the whole worker is terminated, so an infinite while loop only turns the status into “timed out” while the page stays usable.
What does the sandbox disable?
fetch, XMLHttpRequest, importScripts, WebSocket and EventSource are replaced with stubs that throw on call, so there is no way to reach the network; there is also no window or document (workers have no DOM), and being a classic worker it supports neither import nor top-level await. One caveat: this is an environment that prevents mistakes and freezes, not a security boundary — do not run untrusted third-party code in it.
How does console.log end up on the page?
The worker’s console is replaced with a custom implementation: every argument is formatted (strings as-is, numbers and booleans stringified, objects as compact JSON, functions by name, errors as “name: message”), joined into one line and posted back to the main thread, which appends it with a colour per log / info / warn / error / debug level.
Do I keep the output after a timeout or an error?
Yes. Lines are appended as they arrive; a timeout or runtime error only changes the status and terminates the worker, leaving everything already printed in place — which is exactly what you need to see where a loop got stuck. Use “Clear output” to wipe it manually.
Is the code uploaded or stored?
No. The code lives in page memory only, disappears on refresh, and the page makes no requests — and inside the sandbox no request could be made anyway.
Keywords：run javascript onlinejs sandboxcode runnerweb workerconsole capture在线运行 JS代码运行器JS 沙箱JavaScript 在线执行代码片段调试