SoapUI Review 2026: The Free Workhorse That Still Owns SOAP
A heavyweight Java desktop client that refuses to die — and for WSDL-heavy estates, that's a good thing.
Overview
Installing SoapUI Open Source is still a five-minute job: grab the installer or the tarball from SmartBear's site, unpack it, and run the shell script. The catch is Java — the bundled JVM in 5.7.x is old enough that you'll want to point SOAPUI_HOME at your own JDK 11/17 and tune JAVA_OPTS if you're on a laptop with less than 8 GB free. The Swing UI looks like 2011 and behaves like it, but everything you need is there: WSDL import, request generation, assertion editors, and a Groovy console that quietly does most of the heavy lifting once you outgrow the wizards.
Where SoapUI still earns its keep is the service nobody wants to touch: a SOAP endpoint with a WSDL, WS-Security headers, and a schema that returns deeply nested faults. Import the WSDL, and you get every operation scaffolded with a valid envelope in seconds. From there I layer XPath assertions on the response body, a property transfer to carry a session token from login into the next request, and a Groovy step to sign the header. That whole flow — generate, assert, chain, script — is the thing modern REST tools still fumble.
The pros are concrete. WSDL-first generation saves hours on enterprise integrations. Assertions are genuinely deep — schema compliance, XPath, XQuery, JSONPath, script, and response SLA all in one place. Data-driven testing via a properties file or datasource step is baked in. Mock services spin up from a WSDL or a sample response and let you unblock frontend work before the backend exists. And the Groovy hooks mean there is essentially no ceiling; if the UI can't do it, ten lines of script will.
The cons are just as concrete. Project files are one giant XML blob, so two engineers editing the same project produce merge conflicts that read like noise. The UI is slow to open large projects and eats RAM. The Open Source edition has been effectively frozen for years, which means no modern auth flows, no OpenAPI 3.1, and dated TLS defaults you'll need to patch via JVM flags. Reporting out of testrunner is functional but ugly, and you'll be post-processing JUnit XML to get anything readable in CI.
My rule of thumb: greenfield REST work goes to Bruno, Postman, or plain HTTP files under version control. But if you're staring down an entrenched SOAP contract with WS-Security and a decade of WSDL versions, SoapUI is still the fastest path to a real regression suite — especially run headlessly through testrunner in a pipeline. Treat the project file as a build artifact you commit reluctantly, keep the logic in Groovy rather than the UI, and it'll hold up better than its age suggests.
How we scored it
Pricing
In practice
SOAPUI_HOME=/opt/soapui-5.7.2
"$SOAPUI_HOME/bin/testrunner.sh" \
-s "UserServiceSoapBinding TestSuite" \
-c "GetUserById" \
-Penv=staging \
-Penvironment.endpoint=https://staging.api.example.com/ws \
-f ./reports -j -r \
./projects/users-soapui-project.xmlThe headless testrunner is what turns SoapUI from a desktop toy into something you can actually gate a deploy on.
Quick verdict
Best-in-class for WSDL-first SOAP testing with security headers and deep assertions; mediocre for everything else.
Use it if: you own or consume SOAP services, need WS-Security or schema-level validation, or must generate mocks from a contract.
Skip it if: your stack is REST/GraphQL, your team edits test projects concurrently, or you want a tool that shipped a meaningful feature this decade.
Run it headlessly through testrunner in CI and keep assertions in Groovy — that's the configuration that ages well.
Pricing breakdown
SoapUI Open Source: free, EUPL-licensed, no seat limits, no support. This is the edition most engineers actually mean when they say 'SoapUI.'
ReadyAPI Test: commercial per-seat annual subscription, roughly in the high hundreds of dollars per user per year at list price — you're paying for the maintained UI, data-driven features, and support.
ReadyAPI Performance and Virtualization: separate add-on licenses, each a few thousand dollars per seat per year; bundling them into a suite is where SmartBear's quotes get interesting.
Practical advice: Open Source plus a JVM you control covers most regression needs. Only move up when you need maintained TLS/auth support or an official support contract. Confirm current list prices with SmartBear — they change.
Verdict
SoapUI Open Source remains the most complete free option for WSDL-driven testing, and its Groovy scripting layer is genuinely powerful once you get past the dated Swing UI. It is slow to start, memory-hungry, and the paid ReadyAPI tier is priced for enterprises rather than individuals. If your stack is REST-first and greenfield, look elsewhere; if you're staring down a SOAP contract with twelve operations, nothing free comes close.
DevKit Central is editor-independent. Some links are affiliate links; we may earn a recurring commission if you subscribe. This never affects our verdicts.