Code-Similarity Tools for CS Departments (2026)

Computer science departments running a capstone project, an undergraduate thesis or a graduate research course need a check that understands tokenised source code — variable renaming, statement reordering and whitespace changes defeat a prose-oriented similarity engine, which is the specific gap that makes a general-purpose academic integrity contract insufficient on its own for a CS programme.

The evaluation criteria that actually separate these tools

Five columns in the table above are the ones worth defending to a procurement committee, and each maps to a different institutional stakeholder.

• Detection method, not detection accuracy. All five tools use some form of tokenisation-and-fingerprinting approach rather than a plain text diff, which is the baseline requirement for catching a renamed-variable or reordered-function submission. None of the vendors publish a directly comparable false-positive rate across languages, so a department evaluating them should run its own pilot corpus — a set of prior-term submissions with known outcomes — through each candidate before committing, rather than relying on a vendor’s own accuracy claims.
• LMS and API integration is what the CIO and the department’s own administrative staff actually feel day to day. A tool with no LMS plugin means someone builds and maintains that integration, which is a real ongoing engineering cost even for a well-resourced department.
• Data residency is the data protection officer’s question, and it is not the same question as GDPR compliance in the abstract — a vendor can be GDPR-compliant on paper while still processing data outside the EU under a standard contractual clause, which some institutions’ own policies will not accept regardless of the paperwork.
• Cost model determines who approves the purchase. A free, self-hosted tool needs an IT operating-budget line and staff time rather than a procurement signature, which routes the decision through an entirely different committee than a per-institution SaaS licence does.
• Language coverage should be checked against the department’s actual course list, not a vendor’s marketing page — a tool that lists “30-plus languages” may cover the introductory-course languages well and the niche languages used in a graduate systems course poorly, which only shows up when you test against your own submissions.

Why Turnitin does not solve this on its own

Turnitin’s similarity engine is built to compare natural-language prose against a corpus of publications, web pages and prior student submissions. It was never architected to tokenise source code the way a purpose-built code-similarity tool does, so submissions that have been superficially altered — renamed variables, reordered functions, reformatted whitespace — frequently pass a prose-oriented check that would catch the same alteration in an essay. An institution that already runs Turnitin for written assignments, as detailed in our comparison of Tesify and Turnitin for institutions, still needs a second, code-specific tool for a CS department’s submissions; this is a genuine two-purchase situation rather than a gap either vendor is quietly filling.

MOSS: the free default, with real limits

MOSS, run by Stanford, is the tool most computer science departments have already used at least once — it is free, requires only a short registration, and covers a wide range of teaching languages. Its limits are structural rather than accidental: there is no institutional dashboard, no case-management workflow, no audit trail beyond the similarity report itself, and submitted code is processed on Stanford-operated servers outside the submitting institution’s own data-residency perimeter. For a single instructor running an occasional check on one course’s submissions, that trade-off is usually acceptable. For a department that needs a documented, auditable process across every CS course every term, it is not enough on its own.

JPlag: the self-hosted option for departments that care about data residency

JPlag is open source and designed to run on infrastructure the department controls, which makes it the direct answer to a data protection officer’s question about where student code is processed: nowhere but the institution’s own servers. It covers the same class of teaching languages as MOSS, is actively maintained, and can be scripted into a continuous-integration pipeline so that similarity checking runs automatically against every submission rather than being run manually per assignment. The cost is operational rather than financial: someone in the department or in central IT has to install, run and maintain it, which is a real ongoing commitment that a cloud SaaS product removes.

Codequiry and CodeGrade: the commercial dashboard tier

Codequiry and CodeGrade both sit a tier above MOSS and JPlag in what they offer an administrator: a persistent dashboard, case management for flagged submissions, and an API rather than a command-line tool. The meaningful difference between them for an institution weighing this comparison is integration and hosting. Codequiry offers an API and webhook model that a department’s own developers can wire into an existing system, but has no native LMS plugin, so the integration work falls on the institution. CodeGrade ships native plugins for Canvas, Brightspace and Blackboard and pairs similarity checking with an autograding engine, which is a genuine two-in-one for a department that already wants automated grading for programming assignments — and it offers an EU-hosted option from a Netherlands-based company, which matters directly for the GDPR posture question raised in where student text is actually processed.

The recommendation

For most CS departments in the institutions this comparison targets, CodeGrade is the strongest default: native LMS integration removes the largest source of adoption friction, the EU-hosted option answers the data residency question directly rather than deferring it to a vendor data-processing agreement negotiation, and the paired autograding engine gives a second budget line a reason to approve the same contract. The named alternative is JPlag, for a department where self-hosting is already standard practice, where central IT has the capacity to run and maintain the tool, or where the institution’s data protection office is unwilling to approve any code leaving its own infrastructure at all — in that profile, a free, actively maintained, fully self-hosted tool is the more defensible choice than any SaaS product regardless of its hosting region.

Running a pilot before the full purchase

Whichever tool leads the shortlist, run it against a pilot corpus before signing a department-wide contract. Pull a set of anonymised submissions from a prior term where the outcome is already known — including any confirmed integrity cases and a sample of clean submissions — and check whether the candidate tool reproduces the known findings without an unacceptable rate of false positives on the clean set. This is the same discipline set out more generally in how to run a departmental pilot of an AI writing tool, applied here to a code-specific evaluation rather than a writing platform: a vendor’s demonstration environment is not evidence about how the tool performs against your own department’s actual codebase style, assignment structure and course languages. Budget two to three weeks for this pilot against a single course before extending a shortlisted tool to the whole department, and involve the course instructors who will actually review flagged cases, since their judgment about what counts as an acceptable false-positive rate is what a procurement committee is ultimately buying alongside the software.

Where a writing platform fits alongside a code-similarity tool

None of the five platforms above check the written component of a CS capstone or thesis — the report, the literature review, the methodology write-up that accompanies the code and that most programmes grade as a substantial fraction of the final mark. That is a genuinely separate check running against a different kind of artefact, which is why the comparison in what academic writing tools actually check is worth reading alongside this one: a code-similarity tool and an academic writing platform are not competing purchases, they are two checks against two different parts of the same submission. A procurement process evaluating both should treat them as separate line items with separate evaluation criteria rather than asking one vendor to cover both, which is set out more generally in the procurement question bank for an AI writing vendor.

If you are evaluating how an AI academic writing platform fits alongside your existing or planned code-similarity tooling, request an institutional evaluation and we will map the two against your CS department’s actual assessment structure.

Frequently asked questions

Can Turnitin detect plagiarised source code?

Not reliably. Turnitin’s similarity engine is built for natural-language prose, not tokenised source code, so structural changes that a code-specific tool catches — renamed variables, reordered functions — frequently pass a prose-oriented check undetected.

Is MOSS still free to use?

Yes. MOSS remains free and requires only a short registration, but it has no institutional dashboard, no case-management workflow, and processes submissions on Stanford-operated servers outside the submitting institution’s own data-residency perimeter.

What does self-hosting JPlag actually require?

Installation and ongoing maintenance by the department or central IT, and ideally integration into a continuous-integration pipeline so checks run automatically. In exchange, submitted code never leaves institution-controlled infrastructure.

Does CodeGrade replace a separate autograding tool?

For many programming assignments, yes — it pairs similarity checking with an autograding engine in the same product, which is one of the reasons it fits a CS department’s budget conversation more easily than a similarity-only tool.

Which of these tools has an EU data residency option?

CodeGrade, through its Netherlands-based hosting option. MOSS is US-hosted with no residency choice. JPlag’s residency is whatever the institution chooses, since it runs on infrastructure the department controls.

Do any of these tools also check the written report that accompanies a CS thesis?

No. All five are source-code tools. The written component — report, literature review, methodology — needs a separate academic writing and integrity check run against a different kind of artefact.

Is a per-seat or per-institution licence more common for the commercial options?

Codequiry and CodeGrade both licence per institution rather than per seat, which is the more common structure for a departmental or institution-wide integrity tool, though exact terms should be confirmed directly with each vendor during procurement.

Should a department run more than one code-similarity tool at once?

Rarely necessary. The tools above overlap substantially in detection method; the meaningful differences are in hosting, integration and case management rather than raw detection capability, so the choice is usually about institutional fit, not stacking coverage.

How long should a pilot run before a department-wide purchase?

Two to three weeks against a single course, using a set of anonymised prior-term submissions with known outcomes, is usually enough to judge false-positive behaviour and language coverage against your own codebase style before extending the tool department-wide.

Do vendor-published detection accuracy figures mean much on their own?

Not without independent verification. None of the vendors compared here publish a directly comparable false-positive rate across languages, so a pilot run against your own prior-term submissions is more informative than any published figure.