Introduction

In Spring Boot, the embedded Tomcat version is usually determined by Spring Boot’s dependency management, not by a manual server installation on your machine. That means the most reliable way to find the version is to inspect the resolved dependencies for your application or query Tomcat programmatically at runtime.

Check the Dependency Tree First

If your project uses Maven, the dependency tree is often the quickest answer.

mvn dependency:tree | grep tomcat

That shows which Tomcat artifacts were actually resolved, such as tomcat-embed-core, and which version Boot selected for them.

In Gradle, the equivalent inspection is usually:

./gradlew dependencies --configuration runtimeClasspath | grep tomcat

This is often better than guessing from the Spring Boot version alone, because your project may override the default managed Tomcat version.

Programmatic Check at Runtime

If you want to know the embedded Tomcat version from inside the running application, query Tomcat directly.

1import org.apache.catalina.util.ServerInfo;
2
3public class TomcatVersion {
4    public static void main(String[] args) {
5        System.out.println(ServerInfo.getServerNumber());
6    }
7}

That approach is useful when you need to log the actual server version at startup or verify what is running inside a packaged application.

Spring Boot Version Gives a Strong Hint, but Not a Guarantee

Spring Boot release lines typically map to a default servlet container line, and in many projects that is enough to estimate the Tomcat version family. But it is still only a default. If your build overrides Tomcat artifacts directly, the actual embedded version can differ from what the Boot release notes suggest.

That is why dependency inspection is more reliable than relying on memory of version mappings.

Look at the Built Artifact If Needed

In packaged applications, you can also inspect the embedded jars inside the built archive.

jar tf target/app.jar | grep tomcat

This is useful in deployment debugging when you want to verify what went into the artifact rather than what the source build file appears to request.

Why the Exact Version Matters

Tomcat version details matter for:

• servlet and web feature compatibility,
• security patch verification,
• debugging production behavior,
• aligning with organization patch policies.

When a vulnerability advisory or compatibility issue names a specific Tomcat line, knowing the real embedded version becomes operationally important.

Dependency Management Usually Owns the Version

In most Spring Boot projects, you do not declare every Tomcat artifact version manually. Boot’s dependency management or BOM picks a consistent set. That is convenient, but it also means the true answer lives in resolved dependencies rather than in assumptions about the starter dependency name alone.

Common Pitfalls

• Assuming the machine-installed Tomcat version matters for a Spring Boot app that uses embedded Tomcat.
• Guessing from the Spring Boot version without checking dependency overrides.
• Looking only at source build files instead of the resolved dependency tree or packaged artifact.
• Forgetting that runtime inspection may be the easiest answer in a deployed environment.
• Confusing embedded Tomcat libraries with a separately managed external servlet container.

Summary

• The embedded Tomcat version in Spring Boot is usually best discovered from resolved dependencies.
• mvn dependency:tree and Gradle dependency reports are the fastest build-time checks.
• ServerInfo.getServerNumber() is a simple runtime verification method.
• Spring Boot version gives a default hint, but overrides can change the real Tomcat version.
• Check the built artifact when deployment reality matters more than source configuration.