Customizing Matplotlib with Style Sheets

Let’s get our hands dirty. If you’ve spent any time with Matplotlib, you’ve probably written some variation of this code a hundred times to check if your data makes sense:

import matplotlib.pyplot as plt
import numpy as np

x = np.linspace(0, 10, 100)
y = np.sin(x) * np.exp(-x / 3)

plt.plot(x, y)
plt.title('Default Matplotlib Plot')
plt.xlabel('Time')
plt.ylabel('Amplitude')
plt.show()

And you get… well, you get the default Matplotlib plot. It’s functional, certainly. It conveys the information. But it’s the visual equivalent of a beige cubicle wall. There’s no spark, no opinion, no aesthetic signature. For years, this was the reality of quick-and-dirty plotting in Python. Then a single function call changed the game entirely.

Let’s pull the lever and see what happens when we step through the looking glass. Add one line of code to the top of your script, right after the imports:

plt.style.use('ggplot')

Now, run the exact same plotting code again. Bam. Night and day. Suddenly you have a gray background, a clean white grid, thicker lines, and a modern font. It is as if we’ve swapped out the entire rendering engine with a single command. But we haven’t. So what’s really going on here?

The plt.style.use() function is our entry point into a pre-packaged world of aesthetics. Matplotlib ships with a whole wardrobe of these styles, and you can see what’s in the closet by checking a simple attribute:

print(plt.style.available)

That’s a healthy list. Each one of those strings is a key to a different visual universe. Let’s try another one, a favorite for its data-journalism pedigree, fivethirtyeight:

import matplotlib.pyplot as plt
import numpy as np

# Apply the 'fivethirtyeight' style
plt.style.use('fivethirtyeight')

x = np.linspace(0, 10, 100)
y = np.sin(x) * np.exp(-x / 3)

plt.plot(x, y)
plt.title('FiveThirtyEight Style')
plt.xlabel('Time')
plt.ylabel('Amplitude')
plt.show()

Again, a complete transformation. The plot now has that signature light-gray background, no top or right spines, a bold title, and a specific color cycle. It is an instant opinion, baked right in. This isn’t just changing a color; it is adopting a whole visual philosophy with one line of code.

This isn’t black magic. When you call plt.style.use('some_style'), Matplotlib searches its directories for a file named some_style.mplstyle. That’s just a plain text file containing a list of key-value pairs that override Matplotlib’s default runtime configuration parameters, or rcParams. Think of rcParams as the master control panel for nearly every visual element you can imagine—font sizes, line widths, colors, grid visibility, tick marks, and hundreds more. A style sheet is simply a pre-written script that flips a specific set of these switches for you.

The rabbit hole goes deeper. What if one style isn’t quite right? You can combine them. The styles are applied in order, with parameters from later styles in the list overriding the same parameters from earlier ones.

plt.style.use(['seaborn-v0_8-dark', 'ggplot'])

In this case, we’re first laying down the seaborn-v0_8-dark foundation—which provides a dark background, a different grid, and its own color cycle—and then layering the ggplot style on top. Any setting defined in the ggplot.mplstyle file will stomp on the corresponding setting from seaborn-v0_8-dark.mplstyle. It’s a cascade, a last-one-wins system that gives you a surprising amount of compositional power right out of the box. The changes are applied to the global rcParams dictionary, which means every plot you create from this point forward in your script will inherit this new look. That’s an important detail; plt.style.use is not a per-plot function, it’s a session-wide modification. It alters the state of Matplotlib itself for the entire runtime of your code. Understanding this distinction is the key to avoiding unexpected visual shifts when you start building complex, multi-plot figures. The application order is literal, so if style1 sets lines.linewidth: 1 and style2 sets lines.linewidth: 3, using ['style1', 'style2'] results in a linewidth of 3. If you reverse the order, the linewidth becomes 1. This simple mechanism is the first step, but the real power comes when you stop using off-the-shelf styles and start writing your own rulebooks.

Forging Your Own Visual Signature

The pre-packaged styles are great training wheels, but the real power lies in forging your own. Why settle for someone else’s aesthetic when you can define your own visual signature? That is where we graduate from being a consumer of styles to a creator. The process is shockingly simpler.

A style sheet, that .mplstyle file we mentioned, is nothing more than a text file. Its syntax is dead simple: each line specifies a single rcParams parameter, a colon, and its new value. Comments are denoted with a hash symbol (#), just like in Python. Let’s create our own style from the ground up. We’ll call it ‘dark_console’, aiming for a retro, monochrome green-on-black terminal look.

Here’s what the contents of our dark_console.mplstyle file will look like:

# Set background colors for the figure and axes
figure.facecolor: 000000
axes.facecolor:   000000

# Set the color for the axes spines (the box) and ticks
axes.edgecolor:   00FF41
axes.labelcolor:  00FF41
xtick.color:      00FF41
ytick.color:      00FF41

# Set the grid color to be a darker, less obtrusive green
grid.color:       #2C5A2E

# Define the properties of the plot lines
lines.color:      00FF41
lines.linewidth:  2

# Set all text properties
text.color:       00FF41
font.family:      monospace
font.size:        12

# Remove the top and right spines for a cleaner look
axes.spines.top:    False
axes.spines.right:  False

Every line in that file directly targets a specific element of the plot. We’re setting the background to pure black, making all text and essential lines a vibrant green, and even switching to a monospaced font for that classic terminal feel. We’ve also explicitly turned off the top and right axes spines, a common trick to open up the plot and focus attention on the data.

Now, where do you save this file so Matplotlib can find it? Matplotlib looks for style sheets in a specific directory inside its configuration folder, typically located in your user home directory. The path is usually something like ~/.config/matplotlib/stylelib/ on Linux/macOS or C:Users.matplotlibstylelib on Windows. But you don’t have to guess. You can find the correct location programmatically:

import matplotlib as mpl
import os

# Get the config directory path
config_dir = mpl.get_configdir()
stylelib_dir = os.path.join(config_dir, 'stylelib')

# Create the stylelib directory if it doesn't exist
os.makedirs(stylelib_dir, exist_ok=True)

# Define the full path for our new style file
style_file_path = os.path.join(stylelib_dir, 'dark_console.mplstyle')

print(f'Save your style sheet to: {style_file_path}')

Once you’ve saved your dark_console.mplstyle file in that location, Matplotlib will automatically discover it. You might need to restart your Python kernel or script for it to be picked up the first time. After that, using it is as simple as calling any of the built-in styles:

import matplotlib.pyplot as plt
import numpy as np

# Use our newly forged style
plt.style.use('dark_console')

x = np.linspace(0, 10, 100)
y = np.sin(x) * np.exp(-x / 3)

plt.plot(x, y)
plt.title('Custom "dark_console" Style')
plt.xlabel('Time')
plt.ylabel('Amplitude')
plt.grid(True) # We defined a grid color, so let's enable it
plt.show()

The result is a plot this is uniquely yours. It has a strong, consistent aesthetic that can be applied to any plot you make with a single line of code. This is the essence of efficient and personalized data visualization. You’re no longer just tweaking individual plots; you’re defining a comprehensive visual language. You can create different styles for different contexts: one for presentations (‘big_font_projector’), one for publications (‘academic_paper_bw’), and another for internal dashboards (‘company_brand_colors’). The investment of creating a few well-designed style sheets pays dividends in consistency and speed. Any parameter you can set via the rcParams dictionary is fair game. This includes error bar styles, legend placement, figure resolution (DPI), and much more. To find the full list of customizable parameters, you can inspect the matplotlib.rcParams object itself. It is a dictionary-like object holding all the current settings.

Mastering the rcParams Cascade

That matplotlib.rcParams object is the canonical source of truth for Matplotlib’s rendering engine. Everything—from the .mplstyle files we’ve been using to direct function calls—ultimately works by changing values in this master dictionary. Understanding the hierarchy of how these changes are applied is the key to mastering Matplotlib’s appearance. It is a cascade, where settings from more specific sources override those from more general ones. Let’s dissect this cascade layer by layer.

The most fundamental layer is the matplotlibrc file. This is Matplotlib’s configuration file, loaded once when the library is first imported. It is structured exactly like the .mplstyle files we created, but it defines the baseline, default appearance for every plot you make. You can create a custom matplotlibrc in your config directory (the same place you put your stylelib folder) to set your own personal “factory defaults.”

The next layer is the one we’ve already explored: style sheets loaded with plt.style.use(). When you call this function, Matplotlib reads the specified .mplstyle file and updates the rcParams dictionary with the values it contains. This overwrites the defaults loaded from the matplotlibrc file. This change is global for the rest of your script’s execution.

But what if you want to make a change that overrides even the style sheet? You can modify rcParams directly in your script. Any change you make to the plt.rcParams dictionary will take precedence over both the matplotlibrc file and any styles you’ve loaded. That’s the “in-code” override.

import matplotlib.pyplot as plt
import numpy as np

# Start with a known style as our base
plt.style.use('seaborn-v0_8-whitegrid')

# Now, let's surgically override a few parameters at runtime
# These changes will stomp on the values from the style sheet
plt.rcParams['axes.facecolor'] = '#EAEAF2'
plt.rcParams['lines.linewidth'] = 4
plt.rcParams['lines.linestyle'] = '--'
plt.rcParams['axes.grid'] = False # Let's turn the grid off entirely

x = np.linspace(0, 10, 100)
y = np.cos(x) * x

plt.plot(x, y)
plt.title('Runtime rcParams Override')
plt.show()

Here, we loaded the seaborn-v0_8-whitegrid style but then immediately overrode several of its key settings. We changed the background color, made the lines thick and dashed, and even disabled the grid that gives the style its name. The plot obediently reflects our most recent commands. This direct manipulation is powerful, but it is also a blunt instrument. Like plt.style.use(), it affects every plot created from that point forward.

For more surgical control, Matplotlib provides a context manager: plt.style.context(). That is the clean, Pythonic way to apply a style or a set of temporary changes to a specific block of code. Inside the with block, the new styles are active. As soon as the block is exited, Matplotlib automatically reverts all the settings back to what they were before. That is invaluable when you need to create one-off plots with a different look without polluting the global state.

import matplotlib.pyplot as plt
import numpy as np

# Set a global style for the whole script
plt.style.use('dark_background')

x = np.linspace(0, 2 * np.pi, 100)

# --- Plot 1: Uses the global 'dark_background' style ---
plt.figure()
plt.plot(x, np.sin(x))
plt.title('Global Style: dark_background')

# --- Plot 2: Temporarily switch to 'ggplot' for just this plot ---
with plt.style.context('ggplot'):
    plt.figure()
    plt.plot(x, np.cos(x), 'r-') # 'r-' is a direct function argument
    plt.title('Temporary Context: ggplot')

# --- Plot 3: We are now back to the global 'dark_background' style ---
plt.figure()
plt.plot(x, np.tan(x))
plt.title('Back to Global Style')

plt.show()

Notice what happened. The first and third plots adhere to the global dark_background style. The second plot, wrapped in the with plt.style.context('ggplot'): block, looks completely different. The context manager handled the application and cleanup of the ggplot style automatically. This prevents you from having to manually save and restore rcParams settings, which is tedious and error-prone.

This brings us to the complete picture of the cascade. The final, and most specific, layer of control is the keyword arguments you pass directly to plotting functions. In the example above, the plt.plot(x, np.cos(x), 'r-') call inside the context manager uses a red line, even though the ggplot style has its own color cycle. A direct argument to a function will always win, overriding every other setting from any style sheet or rcParams modification for that specific element.

So, the order of precedence, from lowest to highest, is:

1. The matplotlibrc file: The foundational defaults.
2. Style Sheets (plt.style.use()): Overrides the matplotlibrc file. Applied globally for the session.
3. Runtime Changes (plt.rcParams[...] or plt.style.context()): Overrides style sheets. Can be global or temporary.
4. Function Keyword Arguments (e.g., plt.plot(..., color='red')): The ultimate override, applying only to the specific element being created.

This tiered system provides a remarkable degree of flexibility. You can set a broad theme with a style sheet, make specific adjustments for a particular script, and then fine-tune individual plot elements on the fly. It’s a system designed for control, which will allow you to move from broad strokes to fine detail without ever losing command of the final output. The key is to choose the right tool for the job: use style sheets for reusable themes, direct rcParams changes for script-wide tweaks, the context manager for temporary one-offs, and function arguments for the final polish. Once you internalize this flow, you’re no longer just plotting data; you are engineering a visualization with precision and intent. The cascade isn’t a limitation; it’s a ladder of abstraction that lets you operate at whatever level of detail the task demands. That’s the path from simply using Matplotlib to truly mastering it, bending its powerful rendering engine to your exact will. Every parameter is a lever, and now you know the sequence in which they are pulled.

Source: https://www.pythonlore.com/customizing-matplotlib-with-style-sheets/

You might also like this video