Does JPlag Detect AI-Generated Code?

JPlag is one of the standard plagiarism tools in university programming courses, so it is natural to ask whether it can tell when code was written with an AI assistant. The short answer: JPlag does not detect AI authorship. It detects similarity between submissions. Its developers have studied how it behaves with AI-generated and AI-rewritten code, and the results are useful to understand, but they do not change what the tool fundamentally is. The descriptions below come from the official JPlag README and wiki and from a research paper by its developers, which we read in October 2026.

What JPlag actually does

The JPlag README describes it as a tool that finds pairwise similarities among a set of multiple programs and can detect software plagiarism and collusion, even when the code has been obfuscated. An instructor gives JPlag a folder of submissions; it compares every pair and produces a report showing which pairs share code, with the matching sections side by side. The README lists around twenty supported languages, including Java, C, C++, C#, Python, JavaScript, TypeScript, Go, Kotlin and Rust, each with a stated maturity level.

The README and the JPlag wiki also say JPlag runs locally: similarities are calculated on the machine running it, and no source code or results are uploaded. The wiki notes that JPlag is an open-source project developed mainly by researchers at the Karlsruhe Institute of Technology (KIT) in Germany.

The wiki's FAQ shows the practical controls instructors have. Starter code can be excluded with a base-code option, so code everyone was given does not count as a match. Submissions from earlier years can be included as an "old" set. The minimum match length can be tuned, and the wiki warns that lower values increase sensitivity but may lead to more false positives. Nothing in the README or the wiki describes a feature that judges whether code was written by AI.

What JPlag's developers found about AI

The most relevant source is a 2025 preprint by Timur Sağlam and Larissa Schmid, Evaluating Software Plagiarism Detection in the Age of AI. Sağlam leads the JPlag project. The paper tests two defences, implemented in JPlag, against several kinds of automated obfuscation, including AI-based ones, across more than four million pairwise program comparisons. It looks at two separate situations.

• AI used to disguise copied code. GPT-4 was given an existing human solution and asked to rewrite it. The authors report that their defences improved JPlag's ability to separate these disguised copies from unrelated pairs, though the gain was smaller for AI-based rewriting than for simpler tricks such as inserting dead code.
• AI used to write the whole solution. GPT-4 was given only the assignment text. The authors found that GPT-4 solutions to the same task were noticeably more similar to each other than pairs of unrelated human solutions, and that the defences increased this gap somewhat. They suggest this could help when several students use the same model.

Two points are worth keeping in mind. First, both results are about pairs: JPlag can make it more visible that submissions resemble each other, not that one submission was machine-written. Second, this is a single preprint with its own datasets and one model, GPT-4, so it is evidence about how the approach behaves, not a measured detection rate for your course.

The --normalize and --match-merging options

The two defences in that paper, token sequence normalization and subsequence match merging, appear to match two options described in the JPlag wiki. The wiki says the --match-merging option enables heuristic merging of neighbouring matches to counteract obfuscation attempts, and that for Java and C++, the --normalize option ignores dead code and normalizes the order of statements. They can be used together. These options make it harder to hide a copy by shuffling or padding code. They are still similarity features.

Why one AI-written solution is hard for JPlag to see

Similarity tools need something to compare against. If a student writes, or generates, a solution that does not resemble any other submission or any earlier one in the comparison set, there is no match to report. An earlier study on MOSS, a similar tool, illustrates the problem: Biderman and Raff reported in 2022 that solutions generated by GPT-J, an older open model, did not trigger suspicion from MOSS and were diverse in structure. That study did not test JPlag or current assistants, so treat it as background rather than a measurement. For how MOSS compares, see does MOSS detect AI code.

What a JPlag match means for you

• A match is a prompt for review, not a verdict. Short exercises, standard algorithms and code built from the same lecture examples are often similar. A person still has to look at the code.
• No match does not mean no questions. Instructors also compare your work with your earlier submissions and may ask you to explain it.
• Your process is your best evidence. Commits, drafts and the ability to talk through your choices answer both similarity and AI questions.

If you want to understand what other checks courses use, read can professors tell if you used ChatGPT for code.

Checking how your code reads

JPlag needs a whole set of submissions, so running it on your own work tells you little. What you can do is check whether your code shows the style patterns people associate with AI output. Paste it into the detector at the top of this page and read the reasons it lists. If it points to things you did not intend, such as an explanatory comment on every line, you will know what a grader might ask about and can be ready to explain it.

Frequently asked questions

Try the detector

Have a snippet you are unsure about? Paste it into the free AI Code Detector to get a verdict, an AI probability and the reasons behind it. No sign-up, and your code is not stored.