IDE
The debugger
Reading a program and guessing what it did is slow. The debugger lets you stop the program on any line and look at it while it is running.
Start a session
Click a line number in the editor to set a breakpoint. A red dot appears on that line. Then press Debug instead of Execute.
Your program starts and runs normally until it reaches that line, and then it stops. Nothing is lost while it is paused. The program is still there, waiting for you.
You can set as many breakpoints as you like, in any file of a multi-file project. Click the dot again to remove one.
Move through the code
While the program is paused you have four controls:
- Step over runs the current line and stops on the next one. If the line calls a function, the whole function runs and you do not go inside it.
- Step into goes into the function the current line calls, so you can watch it from its first line.
- Step out finishes the function you are inside and stops where it was called from.
- Continue lets the program run on until the next breakpoint, or to the end if there are none left.
Read your variables
The panel beside the editor lists every local variable in the part of the program you are paused in, with its current value. Objects, arrays and structs open up, so you can look inside them instead of printing them.
Beside that is the call stack, which shows how the program arrived at this line. Click any frame in the stack to see the variables as they were there.
Two languages step but do not list variables, because the debugger has no language plugin for them: Fortran and Ada. Breakpoints and stepping work normally for both.
Programs that read input
A debug session is interactive. If your program asks for input while it is paused, you type it in the same place you always do, and the program carries on.
Languages you can debug
Twenty three language and version combinations support debugging today:
| Language | Notes |
|---|---|
| C, C99 | |
| C++, C++ 14, C++ 17, C++ 20, C++ 23 | |
| Java | |
| Python 3 | Python 2 is not supported |
| Go | |
| Rust | |
| Kotlin | |
| Scala | |
| Groovy | |
| Node.js | |
| PHP | |
| Ruby | |
| Perl | Uses Perl's own debugger, focused on the active frame |
| Objective-C | Shows scalar values and C primitives |
| D | Shows primitive and scalar values |
| Fortran | Steps, but does not list variables |
| Ada | Steps, but does not list variables |
| GCC Assembly |
If a language is not on this list, the Debug button tells you so when you press it, and suggests the languages that do support it.
Debugging is added to a language only after it has been tested on the exact image that language runs on, so the list grows slowly and on purpose.
Is this GDB?
People often call an online debugger an online GDB, so it is worth explaining what GDB is.
GDB is the GNU Debugger. It works on programs that are compiled to native machine code, which means languages like C, C++, Objective-C and Fortran. It is the tool most people first meet when they debug a C program, and its name has become a general word for debugging in the browser.
GDB cannot debug Java, Python, Ruby or JavaScript. Those languages do not compile to machine code, so each one has its own debugger, and JDoodle uses the right one for each language. What you get is the same in every case: breakpoints, stepping, variables and a call stack.
So if you came here looking for an online GDB, the short answer is that debugging works here for your language, whichever of the twenty three it is.
How long a session lasts
Debugging is free to use. A session runs for three minutes on the free plan, and ten minutes on Pro and Teacher plans. You can start as many sessions as you need.
Sessions are always interactive, so they use an interactive slot while they are running.