📖 What is a JSP File?
A JSP file is a web page powered by Java. The letters stand for JavaServer Pages, and a file with the .jsp extension is mostly an ordinary web page with pieces of Java code tucked inside, which a Java web server runs to build the page a visitor sees.
Think of it as a web page that can do calculations, look things up in a database or tailor its content to whoever is visiting. A plain HTML page is fixed, but a JSP page can run Java each time it is requested, so the result can differ from one visit to the next. The Java part is handled behind the scenes, and only the finished page travels to the browser.
What sets JSP apart from other page technologies is how the server treats it. Rather than reading the file line by line every time, the server first turns the .jsp file into a small Java program, a servlet, and runs that. Hold on to that single idea and the rest of the format falls into place.
Key Characteristics
- A Java web page, run on the server
- HTML with Java embedded in tags
- Turned into a servlet to run
- Built on the Java platform
Good to Know
- Readable as text in any editor
- Needs a Java server such as Tomcat to run
- The View in a Java web application
- Now called Jakarta Server Pages
⚡ Quick Facts
| File Extension | .jsp |
| Full Name | JavaServer Pages (now Jakarta Server Pages) |
| Developer | Sun Microsystems |
| First Released | 1999 |
| Runs On | A Java web server such as Apache Tomcat |
| Language | Java |
| Built On | The Java Servlet API |
| File Type | Plain text |
⚙️ Turned Into a Servlet
The defining trait of a JSP file is that the server does not run it as written. It converts the page into a Java servlet, a compiled Java class, and runs that instead. This translate-then-compile step is what separates JSP from other ways of building web pages.
The first time a visitor asks for a .jsp page, the Java web server reads the file and generates Java code from it, producing a servlet. It compiles that servlet once, then runs it to build the page and send plain HTML to the browser. On later visits the server reuses the compiled servlet, so it does not repeat the work unless the file has changed. A neat way to remember the relationship is that a servlet is Java with HTML printed out of it, while a JSP is HTML with Java tucked into it. They end up as the same thing, since the page becomes a servlet before it ever runs.
🗂️ What a JSP File Holds
A JSP file is plain text, and inside it a few kinds of content work together to describe both the look of a page and the Java that gives it life.
HTML Markup
The ordinary page layout and text, the familiar tags of any web page.
Embedded Java
Snippets of Java, held in special tags, that the server runs to work things out.
JSP Tags and JSTL
Ready-made tags, including the JSP Standard Tag Library, that handle common jobs without raw code.
The Java parts are set off with their own markers so the server knows what to run. Beginners often write Java directly in scriptlet tags, but modern JSP leans on the tag library and expression language instead, which keeps the page tidy and closer to plain markup. Everything outside those Java parts is passed through to the visitor as ordinary page content.
🔬 Inside the Code
The example below puts the parts side by side. In a JSP the Java sits inside its tags while everything around it is ordinary page content.
A tiny JSP page that greets the visitor
<html> <body> Your address is <%= request.getRemoteAddr() %> <% String who = "visitor"; %> Hello <%= who %> </body> </html> // the server turns this page into a servlet, // compiles it, then runs it to build the HTML
Two kinds of Java tag appear here. The expression tag, opening with a percent sign and an equals sign, prints the value of a single Java expression straight into the page, so the visitor's address appears in place. The scriptlet tag, without the equals sign, holds one or more full Java statements. When this page is requested, the server weaves these fragments into a servlet, compiles it and runs it, and the visitor receives a plain page with the address and greeting filled in.
🏷️ Directives, Tags and the Expression Language
Beyond plain scriptlets, a JSP page has a small vocabulary of its own that keeps pages tidy. Three parts come up most often, and modern pages lean on the last two rather than raw Java.
Directives give the server instructions about the page as a whole and open with a percent sign and an at sign. The page directive, which usually sits at the very top, sets things like the content type or imports a Java package, the include directive pulls another file into the page at translation time, and the taglib directive brings in a tag library. Separately, every JSP page can reach a set of ready-made implicit objects, such as request, response, session and out, without declaring them first. On top of that sits the Expression Language, a compact syntax written with a dollar sign and braces that reads values cleanly, so ${user.name} replaces a whole scriptlet. Together with the tag library, it lets a page show data with almost no Java in sight.
A page directive, the tag library and the Expression Language
<%@ page contentType="text/html" import="java.util.*" %> <%@ taglib prefix="c" uri="jakarta.tags.core" %> <!-- read a value with the Expression Language --> Hello ${ user.name } <!-- loop with a JSTL tag, no scriptlet needed --> <c:forEach var="item" items="${list}"> ${ item } </c:forEach>
Reaching a database follows the same Java-first idea. A JSP page connects through JDBC, the standard Java way to talk to a database, most cleanly by letting a servlet or a helper class run the query and pass the result to the page for display. Writing raw database code directly in a JSP is possible but discouraged, since it mixes logic into a file meant for presentation.
🔁 The JSP Lifecycle
Because a JSP page becomes a servlet before it runs, it passes through a set sequence of stages. Knowing them helps explain why the first request behaves differently from the rest.
Translation
The server reads the .jsp file and generates Java servlet code from it.
Compilation
That generated servlet is compiled into a runnable Java class.
Execution
The servlet runs for each request, building the page and sending HTML back.
Reuse
The compiled servlet is kept and reused until the page changes and needs redoing.
Translation and compilation happen only when the page is new or has been edited, which is why the opening request can lag a moment while the rest feel quick. After that the server simply runs the compiled servlet, so the cost of building it is paid once rather than on every visit.
⚖️ JSP vs Servlet
A common question is how a JSP differs from a servlet, since a JSP becomes one. The difference is really about where you write the code and what each is best suited to.
A servlet is a Java class where you write the program first and print the HTML out of it, line by line, which works well but turns awkward when the page has a lot of layout. A JSP flips that around, letting you write the page as HTML and drop Java in where it is needed, which suits pages that are mostly presentation. In the common Model, View, Controller way of arranging a Java web application, the servlet tends to act as the controller that handles logic, while the JSP acts as the view that shows the result. They are partners rather than rivals, and since every JSP is compiled into a servlet anyway, the choice is about which is easier to write and maintain for a given job.
| Trait | JSP | Servlet |
|---|---|---|
| You write | HTML with Java inside | Java that prints HTML |
| Best for | Presentation and layout | Logic and control |
| MVC role | The view | The controller |
| Extension | .jsp | A compiled .class |
| Relationship | A JSP is translated into a servlet before it runs | |
📂 How to Open a JSP File
Your choice of tool turns on one thing, whether you mean to inspect the file or watch it build a page. Reading a .jsp asks for nothing beyond a plain editor, since the file is text.
A text editor
Open it in Notepad or a similar editor to read and change the source, which is plain text.
A Java IDE
A tool like IntelliJ IDEA or Eclipse understands the Java parts and helps you edit them safely.
A browser, with a Java server
To see the page it makes, request it through a running Java server rather than opening the file.
An IDE earns its keep here because it recognises the Java tags, suggests completions and warns about broken code before you ever deploy the page. The trap to avoid is double-clicking a .jsp and hoping a web page appears. Nothing has translated the page into a servlet or compiled it, so a browser either prints the markup and tags as text or saves the file to your downloads. Turning it into a live page is a separate job, covered next.
▶️ Running a JSP File
Getting a JSP to render as a page, instead of showing its source, calls for a Java web server able to translate and run it. Apache Tomcat is the best known, a free open source container made for the job.
The usual path is to install a Java server such as Tomcat, place your .jsp file inside a web application folder it serves, then request the page through a web address. The server handles the translation into a servlet, the compilation and the running, and returns the finished page. Most Java IDEs can drive a bundled Tomcat for you, which makes testing a page a matter of pressing run rather than setting up a server by hand. For simply reading a .jsp file someone sent you, though, standing up a Java server is more effort than it is worth, and an editor is the quicker route.
🐱 Setting Up Tomcat
Since a JSP needs a Java server, the usual way to run one from scratch is to install Apache Tomcat and drop your page into a small web application it can serve. The shape of that application matters, because Tomcat looks for specific folders.
Install Tomcat
Download Tomcat, unpack it and make sure a matching Java runtime is present on the machine.
Make a web app
Create a folder for your app inside Tomcat's webapps directory, with your .jsp files at its top.
Add WEB-INF
Give the app a WEB-INF folder, which holds the web.xml settings and any compiled classes and libraries.
Start and visit
Start Tomcat, then open the page in a browser through the app's web address to see it run.
The WEB-INF folder is special, since Tomcat hides it from visitors and keeps the application's private parts there, including the web.xml deployment descriptor that describes how the app behaves. Most Java IDEs can create this structure and drive a bundled Tomcat for you, so pressing run both builds the layout and starts the server. Doing it by hand once, though, makes the pieces clear, namely a web app folder under webapps, your pages at the top, and a WEB-INF folder holding the settings.
🏛️ A Short History
JavaServer Pages arrived in 1999 from Sun Microsystems, offered as Java's take on the dynamic web page at a time when Microsoft's ASP and the open source PHP were already popular. Its aim was to let Java developers build pages without writing every tag inside Java code.
Over the years JSP became a standard part of enterprise Java and was widely used to build the visible layer of large business systems. When Oracle handed the Java enterprise platform to the Eclipse Foundation, the technology was renamed from JavaServer Pages to Jakarta Server Pages, though the .jsp extension and the way it works stayed the same. Newer Java frameworks have since taken over much of the ground JSP once held, but plenty of long-running systems still serve .jsp pages, which is why the format remains a familiar sight.
🔄 Editing and Moving On
A frequent request is to convert a .jsp, yet it is program source, not a document, so there is nothing to convert it into. The right move follows from what you are trying to achieve.
If the aim is to alter behaviour, you change the Java and markup in the .jsp itself and the server rebuilds the servlet on the next hit. If the aim is to leave JSP behind, the effort goes into porting the view layer to a newer Java framework, work that belongs to developers rather than any converter tool. And if you merely need a frozen snapshot of a page, loading it from a live server and keeping the returned HTML gives you the output while the Java that generated it stays on the server.
🛠️ Common Issues
Nearly all confusion around JSP files comes back to the same point, that the file needs a Java server. Each common problem has a clear cause.
| Source text appears in the browser | Opened with no Java server behind it. Deploy it to Tomcat and request it to see the built page. |
| File is offered as a download | The host cannot process Java pages. Use a container such as Tomcat that supports JSP. |
| First load is slow | Normal. The page is being translated into a servlet and compiled, which happens once. |
| Confused with a servlet | A JSP is HTML with Java inside, while a servlet is Java that prints HTML. The JSP becomes a servlet to run. |
❓ Frequently Asked Questions
A JSP file is a web page powered by Java. JSP stands for JavaServer Pages, now also called Jakarta Server Pages, and a file with the .jsp extension is mostly HTML with pieces of Java code embedded in special tags. When someone requests the page, a Java web server turns it into a servlet, compiles that, and runs it to build a finished page, sending only plain HTML to the browser. It is Java's way of building dynamic web pages, in the same family as Microsoft's ASP and the open source PHP, but based on the Java platform.
Reading or changing a .jsp calls for nothing fancier than a plain editor, though a Java IDE like IntelliJ IDEA or Eclipse pays off by parsing the Java tags and the surrounding markup. Watching it turn into a real page is different, since a servlet container has to translate and compile the file first, which your browser cannot do alone. When your goal is just to peek at the contents, an editor gets you there with no setup at all.
The page is not passing through a Java server. A .jsp only becomes a web page after a servlet container like Tomcat translates it into a servlet, compiles that and runs it. Loading the file from your own disk, or from a host with no Java support, skips every one of those steps, so the browser treats the markup as text or hands you the file to save. The fix is to place the page on a Java server that supports JSP and request it by its web address.
A servlet is a Java class where you write the program and print the HTML out of it line by line, which suits logic and control. A JSP is the reverse, a page written as HTML with Java dropped in where needed, which suits presentation and layout. In the common Model, View, Controller pattern the servlet often plays the controller and the JSP plays the view. The key link is that a JSP is translated into a servlet before it runs, so they end up as the same kind of thing, just written in different ways.
You need a Java web server, more precisely a servlet container, and the best known is Apache Tomcat, which is free and open source. Other options include Jetty, GlassFish, WildFly and TomEE. The server translates the .jsp page into a servlet, compiles it and runs it. Most Java IDEs can launch a bundled Tomcat for you, so during development you can run a page by pressing a button. What will not work is ordinary shared hosting built for other technologies, since it cannot process Java pages.
The code inside a JSP file is Java. It appears in tags such as scriptlets, which hold Java statements, and expressions, which output the value of a single piece of Java into the page. Modern JSP encourages using the JSP Standard Tag Library and an expression language instead of raw Java, which keeps pages cleaner and closer to plain markup. Around the Java, the rest of the file is ordinary HTML. Because it is built on the Java platform, the code can reach Java features like database access through the standard Java libraries.
Yes. JavaServer Pages was renamed Jakarta Server Pages after stewardship of the Java enterprise platform moved from Oracle to the Eclipse Foundation, which now develops it as part of Jakarta EE. The technology, the way pages are written and the .jsp file extension all stayed the same, so older material calling it JavaServer Pages describes the same thing. In everyday use people still say JSP for both names. The rename reflects the change in who maintains the standard rather than any change in how a .jsp file works.
Install Apache Tomcat and make sure a matching Java runtime is present. Create a folder for your web application inside Tomcat's webapps directory, put your .jsp pages at the top of it, and give it a WEB-INF folder that holds the web.xml settings and any compiled classes and libraries. Then start Tomcat and open the page in a browser through the application's web address. Tomcat translates the page into a servlet, compiles it and runs it. Most Java IDEs can build this layout and launch a bundled Tomcat for you, so during development running a page is often a single button press.
Directives are instructions to the server about the whole page, written with a percent sign and an at sign. The page directive sets things like the content type or imports a Java package, the include directive merges another file at translation time, and the taglib directive brings in a tag library. The Expression Language is a compact syntax written with a dollar sign and braces that reads and shows a value cleanly, so a short expression can replace a whole block of Java. Used with the tag library, it lets a page display data with almost no raw Java, which keeps the page closer to plain markup.
Both build web pages on the server by mixing code into HTML, but they sit in different worlds. JSP is Java based, runs inside a servlet container such as Tomcat, and is translated into a compiled Java servlet before it runs. PHP has its own language, is usually interpreted rather than turned into a servlet, and commonly runs behind Apache. JSP tends to appear in larger Java systems, while PHP is common on smaller sites and much of the wider web. A .jsp file needs a Java server while a .php file needs a PHP-capable one, so most sites commit to just one of the two.
A JSP page reaches a database through JDBC, the standard Java way to connect to one, which opens a link, runs a query and reads the results. The cleaner approach is to let a servlet or a helper class handle that work and pass the finished data to the JSP purely for display, keeping the database code out of the page. You can write JDBC directly inside a JSP, but it is discouraged because it mixes logic into a file meant for presentation. Since JSP is built on Java, it can use the same database libraries as any other Java program.
Implicit objects are a set of ready-made objects that every JSP page can use without declaring them first, because the server provides them automatically. Common ones include request, which carries the incoming browser request, response, which represents the reply, session, which holds data across a visitor's requests, and out, which writes into the page. They give the Java in a page quick access to the web request it is answering. In modern JSP the tag library and Expression Language often reach the same information more neatly, but the implicit objects are still there when raw Java is used.
Yes, though it is a mature technology rather than a first choice for new projects. Many newer Java frameworks now handle the job JSP once did, and a lot of fresh development uses them instead. Even so, JSP was never removed, servlet containers like Tomcat still run it, and a great many long-standing enterprise systems continue to serve .jsp pages. Its rename to Jakarta Server Pages signalled a change of stewardship, not retirement. So while you might not start a new site with JSP, it remains widely maintained in existing systems and worth understanding.
📝 Summary
A JSP file is a JavaServer Pages document, Java's technology for building web pages, released by Sun Microsystems in 1999 and now known as Jakarta Server Pages. A file with the .jsp extension is plain text that is mostly HTML with pieces of Java embedded in tags, such as scriptlets for statements and expressions for output, alongside ready-made tags like the JSP Standard Tag Library. Its defining trait is that a Java web server does not run the file as written but translates it into a Java servlet, compiles that servlet and runs it, sending only the finished HTML to the browser. This translate-then-compile step, done once and then reused, is why the first request can feel slightly slower and why a JSP page always needs a Java server such as Apache Tomcat to work. A plain editor is enough to view or change the source, and a Java IDE such as IntelliJ IDEA or Eclipse smooths the work by reading the Java tags, but rendering the actual page means deploying it to Tomcat or a like server rather than opening it straight from disk. JSP is often compared with a servlet, and the neat way to hold the difference is that a servlet is Java with HTML printed out of it while a JSP is HTML with Java tucked into it, with the servlet acting as the controller and the JSP as the view in a Model, View, Controller design. No genuine conversion exists for a .jsp because it is program source; you edit it in place, and leaving JSP behind means porting the pages to a newer Java framework. Though newer tools have taken over much of its role, many long-running Java systems still serve .jsp pages today.