Servlets have a java definition (applications which handle HTTP GET/POST requests), while portlets have a user interface definition.A component performing a specific function similar to the windows vista widgets or a lot of components used in stackoverflow here. They need not necessarily be backed by servlets on the server side. But the Portlet standard was developed alongside java. O'Reilly has a nice tutorial.
Both portlets and servlets receive an http request and return a response, which is usally some HTML that can be rendered by a browser. A portlet is used in the context of a "Portal", the idea being that a single page seen by the user has lots of parts, think tiles, each coming from a different portlet.
Now, you can get that "tiled" effect from normal servets (See Struts + Tiles for an example of how) the extra bit from the portlets is that the portlets are in a richer environment provided by the Portal, extra APIs are provided so that what is displayed by any portlet can be configured by individual users to their preferences, and the porlets can communicate with each other - press a button in one, something happens in a another.
Portlets are part of JSR-168 standard that regulates portal containers and components. This is different standard from standards for web containers (and servlets). Though there are definitely strong parallels between these two standards they differ in containers, APIs, life cycle, configuration, deployment, etc.
The main difference between portlet vs. servlet could be that while servlet always responds to single type of action - request, portlet (due to nature of its life cycle and stronger container bindings) has to respond to two types of actions: render and request. There are of course more to it but I found this as the core difference between the two when I studied portal development.
Essentially, Servlets provide content that normally takes up the whole page in a browser (unless you're using frames), and portlets provide content that is wrapped by a window. With portlets, you can have multiple portlets side by side with one another and each one can provide content and functionality that is different from the other. A portlet can provide the complete interaction for one type of application, while another portlet can provide content for another type of application. The portal can provide some house keeping functionality and secured single point of entry to all of the portlets on a page. As for the particulars (similarities/differences) between them, please continue reading. Here are some similarities: Servlets and portlets are web based components that utilize Java for their implementation Portlets are managed by a portlet container similar to a servlet container Both of these components generate content, which can be static or dynamic
Servlets and Portlets are web based components which use Java for
their implementation.
Portlets are managed by a portlet container just like servlet is
managed by servlet container.
Both static and dynamic content can be generated by Portlets and
Servlets.
The life cycle of portlets and servlets is controlled by the container
The client/server model is used for both servlets and portlets
The packaging and deployment are essentially the same, WAR/EARs.
Application Session exists in both Servlet and Portlet containers. It is one of the ways of of sharing data (crude Inter-Portlet Communication) from the render phase to the action phase (or any lower phases) in the portlet containers.
Both Servlets and Portlets use similar server / VM environments that support it. Although, some additional configurations might needed in case of portlets to make it tick
The build/DI tools are similar for both - Ant, Maven, Gradle, etc are all supported. Mostly :) - This has changed a bit with Liferay 7.
Dissimilarities
Servlets can render complete web pages, whereas portlets renders html
fragments. These fragments are aggregated by the portal into a
complete web page.
The content type of JSR 168 portlets can be only cHTML, XHTML, WML. It
does not support other content types.
Portlets are not allowed to generate HTML code that contains tags such
as body, frame, frameset, head, html, or title.
A Portlet unlike a servlet doesn’t have URL attached to it so it
cannot be accessed directly. Access is only through the portal page
which holds the portlet.
Portlets can be provided with controls to manipulate its window states
or portlet modes.
Multiple instances of a single portlet can be placed onto the same
page.
Portlets support persistent configuration and customization, profile
information.
Portlets can have two types of request viz. render request and action
request.
Portlets have two scopes within session; application scope for
communication across portlets and portlet scope for intra portlet
communication.
Portlet cannot set the character set encoding of the response nor can
it set the HTTP response headers.
Portlets doesn’t have access to request URL. So it cannot access the
query parameters appended to the URL. Portlets cannot set cookies.
Typical methods of Portlet API are doView(), doEdit(), doHelp() and
processAction() while those of servlet are service(), doPost(),
doGet().
Deployment of Portlets involves different approach than a Servlet application. Some Providers (Liferay/Alfresco/WebSphere) support hot-deploying of portlets without the need to restart the server which is not possible in case of servlets without modularizing the application using special libraries such as OSGi.
Edit(From comments)
A Portlet container is built on a Servlet container. So ultimately it can be said that the portlet runs on a Servlet Container. But while developing apps, we view a portlet container separately from the Servlet/Java EE container.