Spring Boot
JAR vs WAR
Java deployment
web applications
servlet containers

Differences between jar and war in Spring Boot?

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

In Spring Boot, both JAR and WAR packaging contain the same application code, but they target different deployment models. A JAR is usually the default because Spring Boot can run it directly with an embedded servlet container. A WAR is used when the application must be deployed into an external servlet container such as Tomcat.

What a JAR Means in Spring Boot

A Spring Boot JAR is typically an executable archive. It includes your application classes, dependencies, and an embedded web server.

That means you can start the whole application with one command:

bash
java -jar app.jar

This is the usual choice for:

  • microservices
  • containerized deployments
  • command-line services
  • applications managed directly by systemd, Docker, or Kubernetes

The main advantage is operational simplicity. The application and server runtime travel together, so you are not depending on an external Tomcat or Jetty installation.

What a WAR Means in Spring Boot

A WAR is built for deployment to an external servlet container. In that model, the container supplies the web server runtime and loads your application as one deployed unit.

This is often required in:

  • older enterprise environments
  • shared application server installations
  • teams with centralized container administration
  • migrations from traditional Spring MVC or Java EE style deployments

With a WAR, the application server owns startup, shutdown, port management, and many operational settings.

The Key Difference Is Deployment Ownership

The important difference is not file extension alone. It is who owns the servlet container.

For a JAR:

  • your application owns the embedded server
  • you launch the application process directly
  • versioning of the server runtime stays with the app

For a WAR:

  • the external server owns the runtime
  • you deploy into an already-running container
  • server upgrades may be controlled outside the application team

That distinction affects debugging, observability, release flow, and compatibility management.

How the Build Changes

For a Spring Boot JAR, Maven usually keeps the default packaging and includes the embedded server dependency normally.

For a WAR, you package the app as WAR and make the servlet container dependency provided by the external server.

xml
1<packaging>war</packaging>
2
3<dependencies>
4  <dependency>
5    <groupId>org.springframework.boot</groupId>
6    <artifactId>spring-boot-starter-web</artifactId>
7  </dependency>
8
9  <dependency>
10    <groupId>org.springframework.boot</groupId>
11    <artifactId>spring-boot-starter-tomcat</artifactId>
12    <scope>provided</scope>
13  </dependency>
14</dependencies>

You also usually extend SpringBootServletInitializer so the external container can bootstrap the application.

java
1import org.springframework.boot.SpringApplication;
2import org.springframework.boot.autoconfigure.SpringBootApplication;
3import org.springframework.boot.builder.SpringApplicationBuilder;
4import org.springframework.boot.web.servlet.support.SpringBootServletInitializer;
5
6@SpringBootApplication
7public class DemoApplication extends SpringBootServletInitializer {
8
9    @Override
10    protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) {
11        return builder.sources(DemoApplication.class);
12    }
13
14    public static void main(String[] args) {
15        SpringApplication.run(DemoApplication.class, args);
16    }
17}

That same class can still support local execution for development.

Which One Should You Choose

If you are starting a new Spring Boot service, JAR is usually the better default. It is simpler to run, simpler to package into containers, and aligns well with modern deployment platforms.

Choose WAR when you have a real reason, such as:

  • the organization mandates deployment to an external container
  • you are integrating into an existing shared Tomcat platform
  • migration cost would be too high right now

One nuance worth knowing is that an executable WAR is possible in Spring Boot, but if you do not need container deployment, JAR is still the clearer choice.

Common Pitfalls

  • Choosing WAR out of habit when a standalone JAR would be simpler.
  • Forgetting to mark the embedded servlet container dependency as provided for WAR packaging.
  • Assuming WAR is automatically more "enterprise" than JAR. The right format depends on deployment constraints.
  • Deploying to an external container whose servlet or Jakarta level does not match your Spring Boot version.
  • Treating packaging as a purely build-time concern when it also changes operational ownership.

Summary

  • A Spring Boot JAR usually runs as a standalone application with an embedded server.
  • A Spring Boot WAR is intended for deployment to an external servlet container.
  • The real difference is who owns and manages the web server runtime.
  • JAR is the usual default for new services and containerized deployments.
  • WAR is mainly useful when external-container deployment is a hard requirement.

Course illustration
Course illustration

All Rights Reserved.