🐍
Python Compiler
Python 3 Real ExecutionWrite Python 3 code and run it instantly — real backend execution, live stdout/stderr, and stdin support.
main.py
PY3
Standard Input (stdin)
has input
Output
Output will appear here
Press Run or Ctrl+Enter
Executing Python code…
stderr
Category
💻 Developer ToolsKeyboard Shortcuts
Ctrl + Enter
Run code
Ctrl + Z
Undo
Ctrl + Y
Redo
Tab
Indent
Shift + Tab
Unindent
Ctrl + /
Toggle comment
About This Tool
This online Python compiler lets you write Python 3 in the browser and execute it against a genuine interpreter rather than a simulation. You type or paste code into the editor, optionally fill the stdin panel with the input your program will read, and press Run or Ctrl+Enter. The output panel shows whatever the program printed to standard output, any traceback written to standard error, and the process exit code, alongside a line count for the code you submitted. It is aimed at learners working through exercises, developers testing a short snippet or regular expression without setting up a project, and anyone on a locked-down machine who cannot install Python. Execution is capped at 10 seconds per run with an output limit of 64 KB, code is limited to 100 KB, and the temporary file holding your code is deleted immediately after the run completes.
Frequently Asked Questions
It is real execution. Your code is run by an actual Python 3 interpreter in a subprocess on the server, and you receive the genuine standard output, standard error and process exit code. That means tracebacks, exception types and line numbers match exactly what you would see running the same file from a terminal on your own machine.
Yes. Open the stdin panel below the editor and type the input your program should read, with one value per line if you are calling input() repeatedly. The text is piped to the process's standard input, so input() and sys.stdin work normally. Leaving the panel empty when the code calls input() produces an EOFError.
Each run is terminated after 10 seconds, so long loops, sleep calls and heavy computation will be cut off. Output is also capped at 64 KB and submitted code at 100 KB. These limits suit exercises and snippets; anything that needs to run for minutes belongs in a local Python installation instead.
Assume only the Python standard library is available unless you confirm otherwise by running an import and checking the result. There is no package installation step, so libraries such as NumPy, pandas or requests should not be relied on here. Modules like math, json, re, itertools, collections and datetime are part of the standard library.
Interpreted, though with a compilation step inside. CPython compiles your source into bytecode and then executes that bytecode on a virtual machine, rather than producing a native executable the way C or Rust do. That is why syntax errors surface before any output appears, while type errors only appear when the offending line actually runs.
What happens when you press Run
Despite the name, Python is interpreted rather than compiled to a native binary, so what this tool does is execute your source with a real Python 3 interpreter. The internal step Python does perform, compiling source to bytecode, happens automatically as part of that execution.
When you press Run or Ctrl+Enter, the editor contents are posted to the server, written to a uniquely named temporary file, and executed as a subprocess. Anything you entered in the stdin panel is piped to that process's standard input, so calls to input() and sys.stdin.read() behave exactly as they would in a terminal. Standard output and standard error are captured separately and returned together with the process exit code, which is 0 for a clean finish and non-zero when the program raises an unhandled exception or calls sys.exit with an error code.
Several limits keep runs contained. Execution is terminated after 10 seconds, output is truncated at 64 KB, and submitted code is capped at 100 KB. The temporary file is deleted as soon as the run finishes, whether it succeeded or failed.
When you press Run or Ctrl+Enter, the editor contents are posted to the server, written to a uniquely named temporary file, and executed as a subprocess. Anything you entered in the stdin panel is piped to that process's standard input, so calls to input() and sys.stdin.read() behave exactly as they would in a terminal. Standard output and standard error are captured separately and returned together with the process exit code, which is 0 for a clean finish and non-zero when the program raises an unhandled exception or calls sys.exit with an error code.
Several limits keep runs contained. Execution is terminated after 10 seconds, output is truncated at 64 KB, and submitted code is capped at 100 KB. The temporary file is deleted as soon as the run finishes, whether it succeeded or failed.
Worked example: reading input and handling an error
Paste this into the editor:
name = input()
n = int(input())
for i in range(1, n + 1):
print(f"{i}. Hello, {name}")
Then open the stdin panel and enter two lines: Ada, and 3. Press Ctrl+Enter. The output panel shows three lines, numbered 1 to 3, each reading Hello, Ada, and reports an exit code of 0.
Now change the second stdin line from 3 to three and run it again. The program fails at the int() conversion, and the output panel shows a traceback on standard error ending in ValueError: invalid literal for int() with base 10: 'three', with a non-zero exit code. Notice that the first input() still succeeded, so the failure is on the second line, and the traceback names it.
A third run with the stdin panel left empty produces a different error, EOFError, because input() reached the end of the stream with nothing to read. That distinction, ValueError for bad data versus EOFError for no data, is worth recognising when you debug programs that read from standard input.
name = input()
n = int(input())
for i in range(1, n + 1):
print(f"{i}. Hello, {name}")
Then open the stdin panel and enter two lines: Ada, and 3. Press Ctrl+Enter. The output panel shows three lines, numbered 1 to 3, each reading Hello, Ada, and reports an exit code of 0.
Now change the second stdin line from 3 to three and run it again. The program fails at the int() conversion, and the output panel shows a traceback on standard error ending in ValueError: invalid literal for int() with base 10: 'three', with a non-zero exit code. Notice that the first input() still succeeded, so the failure is on the second line, and the traceback names it.
A third run with the stdin panel left empty produces a different error, EOFError, because input() reached the end of the stream with nothing to read. That distinction, ValueError for bad data versus EOFError for no data, is worth recognising when you debug programs that read from standard input.
What this tool is good for, and where it stops
It is well suited to short, self-contained programs: working through a course exercise, checking that a regular expression matches what you expect, confirming how a slice or a comprehension behaves, testing an algorithm against a handful of inputs, or demonstrating a snippet to a colleague. The stdin panel makes it usable for competitive-programming style problems that read their input from standard input.
There are clear boundaries. The 10-second limit rules out long-running loops, sleeps and heavy computation, so an infinite loop will simply be killed. The 64 KB output cap means a program printing thousands of lines will be truncated. There is no file system to write to between runs, no state carried from one run to the next, and no package installation, so assume only the standard library unless you confirm otherwise. Anything requiring a GUI, a network service or a long-lived process is out of scope.
For real projects, install Python locally or use a virtual environment: you will want a debugger, version control, third-party packages and the ability to split code across modules, none of which a single-file runner can provide.
There are clear boundaries. The 10-second limit rules out long-running loops, sleeps and heavy computation, so an infinite loop will simply be killed. The 64 KB output cap means a program printing thousands of lines will be truncated. There is no file system to write to between runs, no state carried from one run to the next, and no package installation, so assume only the standard library unless you confirm otherwise. Anything requiring a GUI, a network service or a long-lived process is out of scope.
For real projects, install Python locally or use a virtual environment: you will want a debugger, version control, third-party packages and the ability to split code across modules, none of which a single-file runner can provide.