How to Run Code on Wandbox

Wandbox runs code in your browser: pick a language, type or paste your program into the editor, optionally supply standard input, then run it and read the output. It works well for quick experiments, sharing snippets, and checking how different compilers or language versions behave, but it is not a full project environment — there is no file system for multi-file builds, so single-file programs are the practical limit.

Step 1: Choose a language

Use the language selector to pick from the supported list. The selector exposes a broad set, including:

Bash script, C, C#, C++, Crystal, D, Elixir, Erlang, Go, Groovy, Haskell, Java, JavaScript, Julia, Lazy K, Lisp, Lua, Nim, OCaml, OpenSSL, PHP, Pascal, Perl, Pony, Python, R, Ruby, Rust, SQL, Scala, Swift, TypeScript, Vim script, and Zig.

Two things to keep in mind:

• C and C++ appear as separate entries (C, C++, and CPP), so choose the one that matches the compiler behavior you want rather than assuming a single "C-family" option.
• Some entries are not general-purpose languages. OpenSSL and SQL are listed alongside the programming languages, so if you select them, expect to write commands or queries rather than a typical program.

Step 2: Enter your code

Type directly into the editor or paste an existing snippet. Because Wandbox compiles and runs a single translation unit, keep everything in one buffer:

• Put #include/import/use statements and all functions in the same editor pane.
• For Java, the public class name must match what the runner expects — if you get a class-name error, rename the class or adjust the code rather than looking for a file-rename option.
• Avoid relying on reading files from disk; there is no project directory to read from.

Step 3: Provide standard input (Stdin)

If your program reads from standard input, enable the Stdin option and enter the input in the text area that appears. This is the equivalent of piping a file into your program locally.

For example, for a program that reads two integers and prints their sum, the Stdin box would contain:

3 4

Then the program's scanf/cin/input()/readLine() calls consume those values. If your program waits for input and you have not enabled Stdin, it will typically block or fail — that is the most common cause of an apparently "hanging" run.

Step 4: Adjust settings, including LSP

The settings area includes Enable LSP and Disable LSP controls. LSP (Language Server Protocol) support provides editor assistance such as diagnostics and completion. Practical guidance:

• Enable LSP when you want feedback while writing, especially for languages where you are unsure of syntax.
• Disable LSP if the language server is slow, noisy, or interferes with a quick run.
• LSP affects the editing experience, not the execution result, so it is safe to toggle either way when you just want output.

There is also a GitHub Login option. Logging in is only relevant if you want the associated account features; running code does not require it based on the available information.

Step 5: Run and read the result

Trigger the run action and inspect the output panel. Expect to see, depending on the language and outcome:

• Program output (stdout) from your print statements.
• Compiler or interpreter errors with line references if the code does not build.
• Runtime errors such as exceptions or non-zero exit statuses.

If the output is empty, check in this order: whether Stdin was needed and enabled, whether the program actually prints anything, and whether a compile error was reported above the output area.

Common sticking points

When Wandbox is the right tool

Use it for single-file snippets, comparing how a language handles a construct, testing standard-input logic, or sharing a reproducible example. For multi-file projects, dependency installation, or persistent storage, a local toolchain or a full container-based environment is a better fit.