Introduction

The embedded Tomcat version in a Spring Boot application is determined by Spring Boot's dependency management, not by any Tomcat installation on your machine. The fastest way to find it is to inspect the resolved dependency tree with mvn dependency:tree | grep tomcat for Maven or ./gradlew dependencies | grep tomcat for Gradle. You can also check it at runtime with ServerInfo.getServerNumber() or by looking inside the packaged JAR or WAR file.

Since Spring Boot manages the Tomcat version through its BOM (Bill of Materials), the version can differ from what you might expect based on the Spring Boot release notes if your project overrides it. Always verify from the actual resolved dependencies rather than assuming.

Method 1: Maven Dependency Tree

The dependency tree is the most reliable build-time check because it shows you what Maven actually resolved, including any overrides.

mvn dependency:tree -Dincludes=org.apache.tomcat.embed

Typical output:

1[INFO] com.example:my-app:jar:1.0.0
2[INFO] \- org.springframework.boot:spring-boot-starter-web:jar:3.2.4:compile
3[INFO]    \- org.springframework.boot:spring-boot-starter-tomcat:jar:3.2.4:compile
4[INFO]       +- org.apache.tomcat.embed:tomcat-embed-core:jar:10.1.19:compile
5[INFO]       +- org.apache.tomcat.embed:tomcat-embed-el:jar:10.1.19:compile
6[INFO]       \- org.apache.tomcat.embed:tomcat-embed-websocket:jar:10.1.19:compile

In this example, the embedded Tomcat version is 10.1.19. The -Dincludes filter narrows the output to only Tomcat artifacts, which is cleaner than grepping the full tree.

Method 2: Gradle Dependency Report

For Gradle projects, use the dependencies task:

./gradlew dependencies --configuration runtimeClasspath | grep tomcat

Output:

|    +--- org.apache.tomcat.embed:tomcat-embed-core:10.1.19
|    +--- org.apache.tomcat.embed:tomcat-embed-el:10.1.19
|    \--- org.apache.tomcat.embed:tomcat-embed-websocket:10.1.19

You can also get a more detailed view with the dependencyInsight task:

./gradlew dependencyInsight --dependency tomcat-embed-core --configuration runtimeClasspath

This shows you exactly why a particular version was selected, including which dependency management rule or override caused it.

Method 3: Programmatic Runtime Check

If you need to verify the Tomcat version from within a running application, use Apache Tomcat's ServerInfo class.

1import org.apache.catalina.util.ServerInfo;
2
3public class TomcatVersionCheck {
4    public static void main(String[] args) {
5        System.out.println("Tomcat version: " + ServerInfo.getServerNumber());
6        System.out.println("Server info: " + ServerInfo.getServerInfo());
7    }
8}

Output:

Tomcat version: 10.1.19
Server info: Apache Tomcat/10.1.19

You can integrate this into your application startup to log the version automatically:

1import jakarta.annotation.PostConstruct;
2import org.apache.catalina.util.ServerInfo;
3import org.slf4j.Logger;
4import org.slf4j.LoggerFactory;
5import org.springframework.stereotype.Component;
6
7@Component
8public class ServerInfoLogger {
9
10    private static final Logger log = LoggerFactory.getLogger(ServerInfoLogger.class);
11
12    @PostConstruct
13    public void logServerInfo() {
14        log.info("Embedded Tomcat version: {}", ServerInfo.getServerNumber());
15    }
16}

This is especially useful in production where you may not have access to the build tools but need to verify a security patch was applied.

Method 4: Inspect the Packaged Artifact

After building your application, you can inspect the JAR or WAR file directly.

1# For a fat JAR
2jar tf target/my-app.jar | grep tomcat
3
4# Typical output
5BOOT-INF/lib/tomcat-embed-core-10.1.19.jar
6BOOT-INF/lib/tomcat-embed-el-10.1.19.jar
7BOOT-INF/lib/tomcat-embed-websocket-10.1.19.jar

The version number is part of the filename. This is particularly useful in deployment scenarios where you want to verify exactly what was shipped, not what the source build file claims.

For WAR files:

jar tf target/my-app.war | grep tomcat
# WEB-INF/lib/tomcat-embed-core-10.1.19.jar

Method 5: Check the Spring Boot BOM

If you want to know the default Tomcat version for a specific Spring Boot release without building a project, check the BOM.

# View the Spring Boot BOM for a specific version
curl -s https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-dependencies/3.2.4/spring-boot-dependencies-3.2.4.pom | grep tomcat.version

Output:

<tomcat.version>10.1.19</tomcat.version>

This is the default. Your project may override it.

Spring Boot to Tomcat Version Mapping

Here is a reference table for recent Spring Boot releases and their default embedded Tomcat versions:

Note that minor patch versions of Spring Boot often bump the Tomcat version for security fixes. This table shows approximate starting versions per release line. Always verify with the dependency tree for your exact Spring Boot patch version.

Overriding the Embedded Tomcat Version

If you need a specific Tomcat version (for example, to apply a security patch before Spring Boot releases an update), override the version property.

Maven

<properties>
    <tomcat.version>10.1.20</tomcat.version>
</properties>

Gradle

ext['tomcat.version'] = '10.1.20'

After the override, verify with the dependency tree to confirm the new version is applied across all Tomcat artifacts (core, el, websocket).

Why the Version Matters

Knowing the exact embedded Tomcat version is important for several practical reasons:

• Security patches: CVE advisories reference specific Tomcat version ranges. You need to know your version to determine if you are affected.
• Feature compatibility: Tomcat 10.x uses the jakarta.* namespace while Tomcat 9.x uses javax.*. This affects library compatibility.
• Bug reproduction: When reporting or investigating a bug, the server version is essential context.
• Compliance audits: Organizations that track software versions for compliance need to report the exact embedded server version.

Common Pitfalls

Confusing the system-installed Tomcat with the embedded one. Spring Boot applications use an embedded Tomcat that is packaged inside the application JAR. The Tomcat installed via apt or brew on your machine is completely unrelated.

Relying on Spring Boot version alone to determine the Tomcat version. Spring Boot patch releases often bump the Tomcat version. Spring Boot 3.2.3 and 3.2.4 may use different Tomcat versions. And your project may override the default.

Forgetting that spring-boot-starter-web pulls in Tomcat by default, but spring-boot-starter-webflux uses Netty. If your application uses WebFlux, there is no embedded Tomcat unless you explicitly added the dependency.

Checking source build files instead of resolved dependencies. A pom.xml might not explicitly mention a Tomcat version because Spring Boot's BOM manages it. The dependency tree is the source of truth, not the build file.

Not verifying after an override. After setting <tomcat.version>, run mvn dependency:tree to confirm all Tomcat artifacts resolved to the expected version. Partial version mismatches across Tomcat modules can cause subtle runtime errors.

Summary

The embedded Tomcat version in Spring Boot is best discovered from resolved dependencies, not from the Spring Boot version number alone. Use mvn dependency:tree or ./gradlew dependencies for build-time verification. Use ServerInfo.getServerNumber() for runtime checks. Inspect the packaged artifact with jar tf when verifying deployed applications. If you need to override the default Tomcat version, set the tomcat.version property and verify all Tomcat artifacts resolve consistently.