To be able to permanently access the data of other services, mashups are generally client applications or hosted online. Since 2010, two major mashup vendors have added support for hosted deployment based on Cloud computing solutions.

In the past years, more and more Web applications have published APIs that enable software developers to easily integrate data and functions instead of building them by themselves. Mashups can be considered to have an active role in the evolution of social software and Web 2.0. Mashups composition tools are usually simple enough to be used by end-users. They generally do not require programming skills, they rather support visual wiring of GUI widgets, services and components together. Therefore, these tools contribute to a new vision of the Web, where users are able to contribute.

The term mashup is also used to describe a remix of digital data.

The history of mashup can be backtracked by firstly understanding the broader context of the history of the Web. For Web 1.0 business model companies stored consumer data on portals and updated them regularly. They controlled all the consumer data and the consumer had to use their products and services to get the information.

With the advent of Web 2.0 a new proposition was created, using Web standards that were commonly and widely adopted across traditional competitors and unlocked the consumer data. Mashups allowed mixing and matching competitor's API to create new services.

The mashup architecture is divided into three layers:

There are many types of mashups, such as data mashups, consumer mashups, and enterprise mashups. The most common type of mashup is the consumer mashup, aimed at the general public.

Mashups can also be categorized by the basic API type they use but any of these can be combined with each other or embedded into other applications.

Mashups and portals are both content aggregation technologies. Portals are an older technology designed as an extension to traditional dynamic Web applications, in which the process of converting data content into marked-up Web pages is split into two phases: generation of markup "fragments" and aggregation of the fragments into pages. Each markup fragment is generated by a "portlet", and the portal combines them into a single Web page. Portlets may be hosted locally on the portal server or remotely on a separate server.

Portal technology defines a complete event model covering reads and updates. A request for an aggregate page on a portal is translated into individual read operations on all the portlets that form the page ("render" operations on local, JSR 168 portlets or "getMarkup" operations on remote, WSRP portlets). If a submit button is pressed on any portlet on a portal page, it is translated into an update operation on that portlet alone ("processAction" on a local portlet or "performBlockingInteraction" on a remote, WSRP portlet). The update is then immediately followed by a read on all portlets on the page.