Demystifying Mapbox Styles

If you've spent any time building digital maps with Mapbox, you've used a style — but you may not have given it much thought. Most tutorials and example code abstract it down to a single URL, and the map just works. That's by design.

But styles are doing a lot more than most developers realize, and understanding how they actually work opens up patterns that are useful whether you're just getting started or have been shipping Mapbox maps for years.

This post pulls back the curtain: what a style really is, how it gets from a server to your screen, and a few tips and tricks for working with styles more intentionally.

What even is a style?

When you load a map in a web or mobile app it is a style that tells the map what to draw and how to draw it. The map rendering library (Mapbox GL JS, or the Maps SDK for iOS/Android/Flutter) loads and parses the style, then fetches whatever data is needed and renders it to the map canvas using GL technology.

The Mapbox Standard Style is the default style for all renderers, but works in a slightly different way than our Classic Styles, but we'll get to that later. First, let's talk about how styles have worked historically.

In the earlier days of Mapbox maps, most developers would start with one of Mapbox's Classic Styles, a URL that looks like mapbox://styles/mapbox/streets-v12. See all of the Slassic Styles here. These styles were professionally designed by our cartographers, and purpose built for different use cases.

• Streets is a great all-purpose style, with a wide variety of colors and details.
• Outdoors is designed for hiking and outdoor activities, with terrain shading, contour lines, and vibrant colors.
• Light and Dark are designed to be more subdued, ideal for maps where the overlaid data should be the star of the show, and the basemap should recede into the background.

With a mapbox:// URL to a classic style, a center point, and a zoom level, you can summon an amazingly detailed, fluidly scrolling map with five lines of code:

new mapboxgl.Map({
    style: 'mapbox://styles/mapbox/streets-v12',
    center: [-103.64548, 51.14245],
    zoom: 1.78
})

What you may not know is that mapbox://styles/mapbox/streets-v12 is shorthand for a call to the Mapbox Styles API, whose sole purpose in life is (you guessed it) storing and serving up map styles! The actual API call is to https://api.mapbox.com/styles/v1/mapbox/streets-v12, which returns the style as JSON:

{
  "name": "Mapbox Streets",
  "sprite": "mapbox://sprites/mapbox/streets-v12",
  "glyphs": "mapbox://fonts/mapbox/{fontstack}/{range}.pbf",
  "center": [
    -92.25,
    37.75
  ],
  "zoom": 2,
  "fog": {...},
  "projection": {
    "name": "globe"
  },
  "visibility": "public",
  "version": 8,
  "layers": [...],
  "sources": {
    "composite": {
      "url": "mapbox://mapbox.mapbox-streets-v8,mapbox.mapbox-terrain-v2,mapbox.mapbox-bathymetry-v2",
      "type": "vector"
    }
  },  
  "created": "1970-01-01T00:00:00.000Z",
  "modified": "1970-01-01T00:00:00.000Z",
  "owner": "mapbox",
  "id": "streets-v12",
  "draft": false
}

The actual JSON is about 13,000 lines long when pretty-printed, and 99% of it is in the layers array. That's really where the action is, where every detail shown on the map is defined, often using complex expressions to handle zoom-dependent styling, multi-language support, etc. Here's just one, of no particular importance, so you can see what we're working with in the layers array. road-minor handles rendering of minor roads. It's a line layer (other types include fill, circle, symbol, etc) and pulls data from the road source layer.

{
  // Identifies this layer within the style.
  "id": "road-minor",

  // Tells the renderer to draw the features as lines.
  "type": "line",

  // Names the source dataset this layer reads from.
  "source": "composite",

  // Chooses the specific source layer inside the vector tileset.
  "source-layer": "road",

  // Prevents the layer from appearing before zoom level 13.
  "minzoom": 13,

  // Limits which road features are included in this layer.
  "filter": [
    "all",
    ["match", ["get", "class"], ["track"], true, "service", ["step", ["zoom"], false, 14, true], false],
    ["match", ["get", "structure"], ["none", "ford"], true, false],
    ["==", ["geometry-type"], "LineString"]
  ],

  // Controls how line ends and corners are shaped.
  "layout": {
    "line-cap": ["step", ["zoom"], "butt", 14, "round"],
    "line-join": ["step", ["zoom"], "miter", 14, "round"]
  },

  // Defines the visible styling, including width and color.
  "paint": {
    "line-width": ["interpolate", ["exponential", 1.5], ["zoom"], 14, 1, 18, 10, 22, 100],
    "line-color": "hsl(0, 0%, 100%)"
  },

  // Stores internal grouping and categorization metadata.
  "metadata": {
    "mapbox:featureComponent": "road-network",
    "mapbox:group": "Road network, surface"
  }
}

All that just for one layer? Yes, and this is one of the simpler ones!

You'll also notice that in the JSON for this style, there are even more magic mapbox:// URLs for the sprite and glyphs, and the sources. sprite and glyphs are similar shorthand URLs for the styles API endpoints that serve additional resources needed to render the style.

sprite gets back an composite image full of all those little icons you see on the map for restaurants, hotels, parks, attractions, etc.

glyphs gets back font files that are used to render all the labels.

sources includes shorthand URLs for a different API, the Mapbox Vector Tiles API. These vector tilesets contain the actual data shown on the map, served over the network as small chunks of unstyled data representing a quadrangle of the earth's surface. mapbox-streets-v8 does the heavy lifting and contains data for most of what you'll see on any Mapbox style (streets, place names, parks/land use, buildings, etc). The image below contains a simplified rendering of the rich data included in the streets-v8 tileset, including streets, place labels, points of interest, building footprints, etc.

All this complexity gets you to a pretty great starting point, a well-designed "basemap" of the whole planet, at every zoom level from the full globe down to streets and intersections. Many developers never need to edit layers in the basemap, they take it as-is and concern themselves only with styling their own data they add to the map. Others may want complete control, changing colors to match a brand, removing or modifying whole sets of map labels, or changing the width of streets.

The Style Specification

The Mapbox Style Specification is the formal definition of what a style is, and how it should be structured. It lives at docs.mapbox.com/style-spec and defines the required properties, valid values for each property, and the overall structure of the style JSON. If you want to understand how styles work under the hood, or if you want to create your own custom styles from scratch, the style spec is the place to start. It is also a great reference for understanding the different properties and options available when working with styles, and can help you troubleshoot issues when your style isn't working as expected.

Every possible style property is outlined in the style spec:

If you are maintaining complex styles on your own, there are various utilities available to help you validate your style JSON against the specification, and to catch errors before they cause issues in your apps.

Other ways to get a style JSON into your map

The mapbox:// URLs are the most common way to get a style into your map, but they are not the only way.

As mentioned earlier, the style is just JSON, and that JSON can come from anywhere. For example, if I were to strip down the complex style JSON above, and include only a single layer for buildings, the style might look like this:

{
        "version": 8,
        "layers": [
            {
                "id": "building",
                "type": "fill",
                "source": "streets-v8",
                "source-layer": "building",
                "minzoom": 15,
                "filter": [
                    "all",
                    ["!=", ["get", "type"], "building:part"],
                    ["==", ["get", "underground"], "false"]
                ],
                "layout": {},
                "paint": {
                    "fill-color": "#ccc",
                }
            }
        ],
        "sources": {
            "streets-v8": {
                "url": "mapbox://mapbox.mapbox-streets-v8",
                "type": "vector"
            }
        }
    }

We have also removed optional properties: center, zoom, fog, projection, visibility, created, modified, owner, id, and draft. Bear in mind that the above is the bare minimum that the renderer needs to display something from the streets-v8 tileset. So how do we get this style into the map?

Load JSON from your codebase

You can load style JSON from a file in your codebase, or as a JSON string defined in your source code. This codepen shows the minimal style JSON above, implemented as a JSON object in the JavaScript code just before map instantiation:

Web

In a web project, this style could be saved as style.json and imported as a JSON object using a bundler:

import style from '../data/style.json' 

...

const map = new mapboxgl.Map({
  style: style,
  center: [-72, 41],
  zoom: 15.5
})

It can also be defined as an object in the JavaScript:

const style = {
  "version": 8,
  "layers": [ ... ],
  "sources": { ... }
}

...

const map = new mapboxgl.Map({
  style: style,
  center: [-72, 41],
  zoom: 15.5
})

Mobile Applications (iOS, Android, Flutter)

For mobile applications, there's no equivalent to loading the style JSON from an object stored in a variable, so you'll be working with the JSON as a string. You can load the JSON from an asset file in your codebase, or define it as a string directly in your code.

For example, in iOS you could load the JSON from a file in your app bundle:

if let styleURL = Bundle.main.url(forResource: "style", withExtension: "json") {
    let map = MapView(frame: view.bounds, styleURL: styleURL)
    view.addSubview(map)
}

Or in Flutter you could define the string directly in your code:

const String style = '''{
  "version": 8,
  "layers": [ ... ],
  "sources": { ... }         
}''';

final map = MapboxMap(
  styleString: style,
  initialCameraPosition: CameraPosition(
    target: LatLng(41, -72),
    zoom: 15.5,
  ),
);

Host a JSON file somewhere (anywhere!)

You can add any URL to the style option in Mapbox GL JS. This means you can host your style JSON on your own server, an S3 bucket, github raw link, or any other web-accessible location. The only requirement is that the style be accessible at the time of map instantiation, and that it be valid style JSON:

const map = new mapboxgl.Map({
  style: 'https://example.com/my-style.json',
  center: [-72, 41],
  zoom: 15.5
})

On mobile, loading a style from a URL works the same way, just make sure the URL is accessible from the device:

let styleURL = URL(string: "https://example.com/my-style.json")!
let map = MapView(frame: view.bounds, styleURL: styleURL)
view.addSubview(map)

When would I ever need to do this?

Loading a style JSON from your codebase can be useful in development, where you want to move quickly and just get something on the screen without worrying about hosting and network requests. It also allows you to keep your style JSON in version control alongside your app's code, which can be helpful for tracking changes and collaborating with other developers.

There are also plenty of use cases where a full-on basemap isn't needed, such as indoor maps, transit maps, event seating charts, or any map where the data is the star of the show and a real-world basemap would just be visual noise. In these cases, you can maintain a simple style JSON with just your custom sources and layers, and load it directly into the map without having to worry about the complexity of a full basemap style.

For a full style with hundreds of layers and thousands of lines of JSON, it's often less practical to maintain it in your codebase, but some teams may prefer this so they can keep styles in the same codebase as their app, be able to explore changes in version control, and have full control over how and when styles are updated and deployed.

However, modern changes to the style spec allow for importing one style into another, which makes maintaining your own top-level style JSON much more manageable. See the Enter the Standard Style (and style "imports") section below.

Implementation patterns for using Mapbox-hosted Classic Styles

1) Load a Mapbox classic style (mapbox://styles/mapbox/streets-v12) and add your data at runtime

This approach treats the initial map load and its style as the basemap and adds additional sources and layers after the map has loaded. This approach lends itself well to using GeoJSON sources and layers when you have small datasets that you want to add to a style.

const map = new mapboxgl.Map({
  style: 'mapbox://styles/mapbox/streets-v12',
  center: [-72, 41],
  zoom: 15.5
})

map.on('load', () => {
  map.addSource('my-data', {
    type: 'geojson',
    data: 'https://example.com/my-data.geojson'
  })

  map.addLayer({
    id: 'my-data-layer',
    type: 'circle',
    source: 'my-data',
    paint: {
      'circle-radius': 5,
      'circle-color': '#f00'
    }
  })
})

2) Make a custom style based on (e.g. cloned from) a Mapbox-hosted style

With this approach, you start with a clone of a Mapbox style and add your data in the Mapbox Style Editor. Once your style is published, you can use it in your frontend maps using its mapbox:// URL. Behind the scenes there is still a style JSON with thousands of lines, but you the developer never have to interact with it directly, and can make all changes through the UI of the Style Editor.

This approach is more common for developers who have custom tilesets hosted on Mapbox, either created using Mapbox Tiling Service or via the Data Workbench. Adding a custom tileset as a vector source at runtime is still possible, but it's more straightforward to add the tileset to a custom style and use the Style Editor to get it looking the way you want.

This image from the Style Editor shows the Dark classic style, with full control over each of its 100+ layers. Developers get full control, but manual updates are required if the underlying data changes or new features are released.

This approach is also ideal if you want the same map on multiple platforms, as you can maintain one style in the Style Editor and load it on web, iOS, Android, and/or Flutter with the same mapbox:// URL. No additional code is necessary to add your custom sources and layers, as they are already baked into the custom style.

Note: The Style Editor used to allow for the creation of new styles based on the Classic Styles (Streets, Light, Dark, etc.), but this option has been removed. You can still use this approach by adding any of the styles in the Mapbox Gallery's Community Templates tab. Copying a style from the gallery clones it, and your new style is a carbon copy of the original template. Any changes you make are yours to manage.

const map = new mapboxgl.Map({
  style: 'mapbox://styles/your-username/your-style-id',
  center: [-72, 41],
  zoom: 15.5
})

The "Maintenance Tax" of Classic Styles

The classic style paradigm has been around since the earliest days of GL-based mapping at Mapbox, and it remains a powerful and flexible approach — but that flexibility comes with a cost: you own the style JSON, which means you own the maintenance burden.

When you fork a classic style, you're taking a snapshot frozen in time. Mapbox continuously improves both the renderer and the style spec together — new features like HD Roads or Indoor Maps aren't just style layer changes, they're coordinated updates across the rendering engine, the style specification, and the style JSON simultaneously. Classic style users who want these features have to manually integrate those style-side changes without breaking their own customizations.

The more custom styles you maintain, and the more heavily you've modified them, the steeper this tax becomes. What's the solution? Read on to learn about how the Mapbox Standard Style changes the whole style paradigm.

Enter the Mapbox Standard Style (and style "imports")

I've spent all this time telling you about the old way of doing things and the underlying structure of a style so I can better explain the value of the new way. The Mapbox Standard Style is our premier, multipurpose basemap. At its core it is a style just like any other, with sources, layers, sprites, glyphs, etc, but it is designed to be imported and configured instead of being cloned and modified. This is a (relatively) new pattern for Mapbox styles, abstracting away the complexity of the basemap and allowing developers to focus their attention on the data they are presenting on top of the basemap.

In fact, when you load a map with the Mapbox Standard Style (either by not specifying a style at all, or by using the mapbox://styles/mapbox/standard URL), the renderer actually creates a new style on the fly that imports the Standard Style. The style that's actually loaded looks something like this:

{
  "version": 8,
  "sources": {},
  "layers": [],
  "imports": [
    {
      "id": "basemap",
      "url": "mapbox://styles/mapbox/standard"
    }
  ]
}

Mapbox Standard also introduces the concept of slots, which are placeholders in the layer stack of the imported style where any custom layers from the importing style can be inserted. For example, you may want your custom polygon layer to appear above paths and roads, but below buildings, models and labels, so you could place it in the middle slot. For more on slots in Mapbox Standard, see the Mapbox Standard Style documentation.

But what if you want to modify the individual layers in the Standard Style? Direct manipulation of these layers is not possible. This is part of the tradeoff of style imports. Instead of direct access to the layers, the style has been designed with a set of configurable properties. Think of it as an API for the style. You can summon standard with or without map labels, set the color of water, land, and park areas, and toggle 3D buildings.

Here's what that looks like in a Style JSON:

{
  "version": 8,
  "sources": {...},
  "layers": [...],
  "imports": [
    {
      "id": "basemap",
      "url": "mapbox://styles/mapbox/standard",
      "config": {
        showPlaceLabels: false,
        show3dObjects: false,
        colorWater: '#00F',
      }
    }
  ]
}

Best of all, the Standard Style is in continuous development, and because you are importing it instead of copying it, you get all the updates and improvements as they are released, without having to do any work to maintain it.

Implementation Patterns for the Mapbox Standard Style

Here I'll outline three common patterns for implementing the Mapbox Standard Style in your maps, and the pros and cons of each.

1. Instantiate with standard + config parameters, add data as runtime layers and/or Markers/Annotations

Mapbox Standard is now the default style for all Mapbox renderers, so specifying a style when you instantiate a map is no longer required. The renderers also accept config properties during map instantiation, so you can configure the Standard Style without having to create style JSON.

const map = new mapboxgl.Map({
  center: [-72, 41],
  zoom: 15.5,
  config: { // configure the Mapbox Standard Style before the map loads
    basemap: {
      showPlaceLabels: false,
      show3dObjects: false,
      colorWater: '#00F',
    }
  }
})

map.on('load', () => {
  map.addSource('my-data', {
    type: 'geojson',
    data: 'https://example.com/my-data.geojson'
  })

  map.addLayer({
    id: 'my-data-layer',
    type: 'circle',
    source: 'my-data',
    paint: {
      'circle-radius': 5,
      'circle-color': '#f00'
    }
  })
})

Pros:

• Simple and straightforward, with no need to maintain any style JSON
• Always up to date with the latest version of the Standard Style
• Configurable without needing to understand the complexity of the style JSON
• The basemap "just works" and you focus on adding your data after the map loads

Cons:

• Duplicate client-side configuration if you are using the same style on multiple platforms (web, iOS, Android, Flutter)
• Verbose if you are adding a lot of runtime layers and sources, as all of that has to be done in code instead of in a style JSON.

2. Create a custom style JSON that imports the Standard Style, and load the map with the custom style's URL

This approach means crafting your own style JSON, but it's a more manageable size since the Standard Style is abstracted away via an import. You can add your custom sources and layers to the style JSON, and configure the Standard Style via the config property in the import. This style JSON can be hosted anywhere, or included directly in your app's codebase.

const style = {
  "version": 8,
  "sources": {
    "my-data": {
      "type": "geojson",
      "data": "https://example.com/my-data.geojson"
    }
  },
  "layers": [
    {
      "id": "my-data-layer",
      "type": "circle",
      "source": "my-data",
      "paint": {
        "circle-radius": 5,
        "circle-color": "#f00"
      }
    }
  ],
  "imports": [
    {
      "id": "basemap",
      "url": "mapbox://styles/mapbox/standard",
      "config": {
        showPlaceLabels: false,
        show3dObjects: false,
        colorWater: '#00F',
      }
    }
  ]
}

const map = new mapboxgl.Map({
  style: style,
  center: [-72, 41],
  zoom: 15.5
})

Pros:

• Centralized style management in a single JSON file, with no need for client-side configuration
• Still up to date with the latest version of the Standard Style, without having to manage it yourself
• Easier to maintain and update custom sources and layers in a style JSON than in code
• Compatible with GeoJSON, image, and video source types

Cons:

• Requires understanding of the style JSON structure and the concept of imports
• Still requires maintaining a custom style JSON, which may be more work than just adding runtime layers

3. Create a custom style in the Style Editor

All custom styles created via the Mapbox Style Editor now include the Standard Style as an import, so if you are using the Style Editor to create your styles, you are already using the Standard Style under the hood, and can take advantage of all its features and updates without having to do anything extra. You can upload your data to the data workbench, add it to a style, configure the basemap, and get a mapbox:// URL that you can use across all platforms, with the confidence that your basemap is always up to date and looking great.

const map = new mapboxgl.Map({
  style: 'mapbox://styles/your-username/your-style-id',
  center: [-72, 41],
  zoom: 15.5
})

Pros:

• No need to maintain any style JSON, as everything is done through the Mapbox Style Editor and served via a mapbox:// URL
• The most user-friendly way to create and manage styles, with a visual editor and real-time preview

Cons:

• May not be ideal for teams that prefer to manage styles in code or version control, as styles in the Style Editor are not as easily versioned or diffed as JSON files
• Only compatible with vector and raster source types from Mapbox-hosted tilesets. If you want to use GeoJSON, image, or video sources, you would need to add those as runtime sources and layers in your app's code, which may be less than ideal if you have a lot of custom data to add.

Comparing The Standard Style with Classic Styles

Style	Usage approaches	Customization	Updates
Mapbox Standard Style	- Load by style URL; add your data layers at runtime - Create a custom style JSON that imports Standard as a dependency - Build a custom style in the Mapbox Style Editor that imports Standard	- Predefined configuration parameters (no raw layer editing) - Theme via lookup table (LUT) for cohesive color grading - Specify key colors to globally tint the style - Toggle POIs, landmarks, transit on/off - Light presets (day, dusk, dawn, night)	Automatic — Referenced by URL or import, Mapbox continuously updates the style and you receive all improvements (new features, data, rendering quality) automatically, without any action on your part.
Mapbox Classic Styles	- Load a Mapbox-hosted style URL (Streets, Satellite, Outdoors, etc.); add your data layers at runtime - Fork a Mapbox classic style into your own style JSON and customize freely - Create a custom style in the Mapbox Style Editor based on a classic style template, add your own data sources and layers	- Full access to every layer — edit colors, fonts, filters, zoom ranges directly - Add, remove, or reorder any layer - Customize data sources, expressions, and layout properties without restriction	Manual — When you fork or copy a classic style, it becomes a snapshot. You own the style JSON and must manually apply any upstream changes from Mapbox; there are no automatic updates.

Standard Style replaces multiple Classic Styles

The Mapbox Standard Style also includes config parameters for color themes and light presets, and combing these can yield drastically different looks.

With Classic Styles, we had whole different styles for different looks, like streets, light, and dark. Streets was a good all-purpose style for a basemap, with a wide variety of colors and details. Light and dark were designed to be more subdued, ideal for maps where the overlaid data should be the star of the show, and the basemap should recede into the background. With the Standard Style, you can achieve all three looks with one style, and have more control over the colors and details than ever before.

Classic Style	Equivalent using Standard Style
Mapbox Streets	lightPreset: 'day' (default)
Mapbox Light	lightPreset: 'day' + colorTheme: 'monochrome'
Mapbox Dark	lightPreset: 'night' + colorTheme: 'monochrome'

There's no quick configuration to replicate the Outdoors classic style with Mapbox Standard, but there is a style template which imports Standard and adds 3D terrain, hillshading, and topographic lines to get you the same effect. See the Outdoors template in the Mapbox Style Gallery. You can clone this template in the Style Editor and add your own data to it. Keep in mind that you'll get continuous updates to the Standard Style since it's imported, but the additional layers are yours to manage.

Modifying styles at runtime

Layers in a map style can be modified at runtime, and involves passing in bits of layer JSON to the setLayoutProperty and setPaintProperty methods on the map. This is a common pattern for adding interactivity to a map, such as changing the color of a layer when it's clicked, or toggling the visibility of a layer with a button click.

map.setLayoutProperty('my-layer', 'visibility', 'none');
map.setPaintProperty('my-layer', 'circle-color', '#0f0');

Since imported styles don't allow direct control of their internal map layers, control happens using the imported style's config parameters. All Mapbox renderers now include a method for modifying the config parameters of an imported style at runtime. This means you can change the colors, labels, and 3D settings of the Standard Style on the fly, without having to reload the map or create a new style JSON. This could be used to make the light preset (dawn, day, dusk, night) dynamic based on the user's actual time of day, or to toggle place labels on and off with a button click.

map.setConfigProperty('basemap', 'lightPreset', 'dusk');

map.setConfigProperty('basemap', 'showPlaceLabels', false);

See the setConfigProperty example for more details.

Building your own imported styles

While not widely documented, the style import pattern is not limited to just the Mapbox Standard Style. You can create your own styles that are designed to be imported into other styles, and have their own configuration options specific to your needs. This is a powerful pattern for managing complex styles, as it allows you to break down a large style into smaller, more manageable pieces, and reuse common elements across multiple styles.

{
  "version": 8,
  "sources": {...},
  "layers": [...],
  "imports": [
    {
      "id": "basemap",
      "url": "mapbox://styles/mapbox/standard",
      "config": { ... }
    },
    {
      "id": "transit",
      "url": "mapbox://styles/your-username/transit-style",
      "config": { 
        showAcessibleTransit: true,
        showTransitLabels: false,
      }
    }
  ]
}

Other style tips and tricks

Here are a few more tips.

Define GeoJSON source data in the style

You can store data for GeoJSON sources right in the style JSON, instead of linking to it. This is ideal for small datasets that are tightly coupled to the style and don't need to be updated independently. Just add a data property to your source definition and include the GeoJSON directly in the style JSON.

{
  "version": 8,
  "sources": {
    "my-data": {
      "type": "geojson",
      "data": {
        "type": "FeatureCollection",
        "features": [
          {
            "type": "Feature",
            "geometry": {
              "type": "Point",
              "coordinates": [-72, 41]
            },
            "properties": {
              "name": "My Point"
            }
          }
        ]
      }
    }
  }
}

Manipulate a style via code

When working with a style as a JavaScript object, you can provide GeoJSON data as a variable or assemble any part of the object programmatically before using it in a map.

const myData = {
  type: "FeatureCollection",
  features: [
    {
      type: "Feature",
      geometry: {
        type: "Point",
        coordinates: [-72, 41],
      },
      properties: {
        name: "My Point",
      },
    },
  ],
};

const myStyle = {
  version: 8,
  sources: {
    "my-data": {
      type: "geojson",
      data: myData,
    },
  },
};

// Add a source to the style
myStyle.sources.push({
  type: "vector",
  url: "https://someserver.com/path-to-tilejson.json",
});

Define the default camera position in the style

Mapbox renderers honor camera properties (center, zoom, pitch, bearing) from the style JSON, so you can set the initial map view in the style instead of in code. This is useful for ensuring a consistent initial view across platforms, or when maintaining a style separately from the app code. These properties exist at the root of the style object.

{
  "version": 8,
  "center": [58.0, 0.0],
  "sources": {},
  "layers": []
}

Wrapping up

When it comes to styles, you've got options. Whether you just want a quick and easy way to get a map on the screen, or you want complete control over every layer and source, the style specification and Mapbox's tools are flexible and can accommodate your needs.

The Mapbox Standard Style and the style import pattern have made it easier than ever to get a great-looking basemap up and running, while still allowing for customization and control when you need it.

Hopefully this post has demystified some of the magic and recent changes around map styles, and given you some ideas for how to work with them in your own projects. If you have any questions or want to share your own style tips and tricks, feel free to reach out or leave a comment!