JavaScript Runner
Write JS and hit run; captures console.log/warn/error output and shows execution time.
Executed with new Function, console output captured, never leaves the browser.
JavaScript runner: execution context, console capture and the security boundary
How your code gets executed
The tool hands your input to new Function, building a function from it and running it. The consequences:
- The code runs in the current page's JavaScript environment, not a separate sandbox. It can reach
window,document,localStorage,locationdirectly, and can make network requests. - It does not pass through a parser pre-pass, so a syntax error surfaces as a thrown exception that is caught and shown.
- The code runs as an ordinary script (depending on the implementation) outside strict mode, so the meaning of
thismatches a browser script.
This leads to a boundary that must be stated plainly — see the security section below.
How console output is captured
The tool temporarily replaces console.log, console.error, console.warn and friends, collecting their arguments into the output panel. What that means in practice:
| Case | Behaviour |
|---|---|
console.log('a', 1) | shown joined in order |
console.log({a:1}) | depends on the implementation; may show [object Object]; the safe form is JSON.stringify(obj, null, 2) |
console.table / console.group | usually not captured; use log instead |
| the browser devtools console | still available (you can see it there); capture is just an extra copy |
The tool also shows execution time, a rough sense of an operation's scale (comparing two algorithms, or whether a loop is acceptable). But this is a single run's wall-clock time, affected by JIT warm-up and current load — not a benchmark. For real performance, run many iterations in devtools and take the median, or use a dedicated benchmarking tool.
Handling asynchronous code
Support for async is usually limited:
- Output inside setTimeout may not appear. Once execution ends the output panel may have finalized, so callbacks firing later might not be collected. The safe pattern is to wrap async logic in an immediately-invoked async function and await before producing output.
- A Promise rejection may not be caught and can show as "no output" rather than an error. Wrap async code in try/catch.
- Async work you want to wait for needs await — do not rely on the tool to wait for you.
Security boundary — a clear discipline
Because the code executes directly in the page context, it can reach this site's storage and network. This site has no account system and stores no personal data, so the risk is limited, but the discipline still holds:
- Do not run code from unknown sources. A "try this" snippet copied from a forum, chat or gist can absolutely contain logic that reads storage or fires requests.
- Do not put real keys, tokens or passwords in the code. They enter this page environment and may be logged by the network. Use dummy values for testing.
- When you must run untrusted code, use the HTML runner (iframe-based, better isolation), or the browser devtools Snippets, or a separate Node environment.
If you only want to try an algorithm that touches no sensitive data, this tool is convenient; for credentials or untrusted sources, pick the better-isolated option.
Typical uses
- Verify logic: date math, string handling, regex matching, array transforms.
- Probe API behaviour: how
JSON.parsereacts to edge inputs,Intlformatting,Array.sortstability and comparator. - Format data: reshape a blob of JSON with a script, more reliable than by hand.
- One-off conversion scripts: turn CSV text into the snippet you need, paste from the output.
- Debug expressions: break a complex expression apart and console.log the intermediates.
Everything runs locally; the code is not uploaded.
FAQ
Why can't I use top-level const/let?
The code is wrapped in the new Function body, where const/let work fine in function scope; use a function-style return when needed.