You have a MATLAB® toolbox that you want to share with the world. We want to help. To do that, we want to convince you to use the MathWorks Toolbox best practices. It's a little bit of extra work with a big payoff.
This is a continuously evolving document and some best practices may change in the future as MATLAB evolves. We encourage your feedback and suggestions for future revisions. Feel free to open an issue or post to the discussions. Your insights and feedback help us improve this document and make it even more useful for the community. Right now, we're focused on toolboxes that don't have derived files that require a build step, like MEX files or content-obscured files (P-Code). We plan to address those in the future.
Being in a standard format makes it easier for other people to assess and take advantage of your work. Your work is more "legible," because it's in a familiar format. They know, for example, that they can always expect to find a helpful and thorough README.md
file in the top folder. They also know that a good place to start learning how to use your toolbox will be the doc/GettingStarted.mlx
file. These and other best practices help your users build confidence that your toolbox is well built and ready to use.
But the advantages go beyond helping your users. Standard formats also make it easier for you to maintain the toolbox. Tools and systems (such as automated testing on GitHub) will immediately know how to work.
We use the term “toolbox” here to mean a collection of reusable MATLAB code that you want to share with other people. Toolboxes contain not just code files, but also data, apps, tests, and examples. Some toolboxes will be just a few files; others may be extensive and represent years of effort by multiple people. The guidelines we present can be adapted for toolboxes that are large or small, casual or sophisticated. We will step through a comprehensive example with many aspects. There’s no need to do everything all at once -- you can start with a few guidelines and adopt more as you go.
To make it easier to follow, we’ve created a fictitious toolbox for doing basic arithmetic: The Arithmetic Toolbox on GitHub. We’ll use this throughout to show how to apply these design principles. If you'd like to explore a complete toolbox that uses this structure, visit the Climate Data Store Toolbox.
- Root folder is a shortened version of the name of the toolbox
- Put all the materials that you plan to share with your users in
toolbox
sub-folder - Provide a
GettingStarted.mlx
intoolbox/doc
folder to help people get started - Package and distribute your toolbox with MATLAB Toolbox files (
.mltbx
) - Make your toolbox more robust by using tests, MATLAB Projects, source control, and
buildtool
- Add the "Open in MATLAB Online" badge so users can try out your toolbox instantly
Recommended file and folder structure:
<toolboxname>/
| README.md # Overview of toolbox for users and developers
| license.txt # License file
└───images/ # Images for README.md
└───toolbox/
| <toolboxfunction1>.m # Documented functions
| <toolboxfunction2>.m
├───doc/
| GettingStarted.mlx # Getting started guide
├───examples/ # Examples (Live Scripts)
└───private/ # Implementation details, not intended for end users
- Root Folder Name and Contents
- Toolbox Folder
- Packaging and Releasing your Toolbox
- Make your Toolbox more robust
- MATLAB Online and File Exchange badges
- Examples
At the top level of your project is a folder or source repository, which we'll call the root folder. This folder has everything a developer needs to collaborate with you on your toolbox. When you are working in GitHub, this is the repository name, and will be the name of the folder when the repository is cloned.
- To name the root folder of your toolbox, shorten the English name by removing the word "toolbox" and start with a letter. Use only letters, numbers, and underscores. For instance, if your toolbox is named "QuickerSim CFD Toolbox for MATLAB," the root folder might be named "quickerSimCFD." Following this naming convention will guarantee the validity of your toolbox in every operating system and source control system you use, eliminating the need to rename it in the future whenever you migrate to new systems.
- Include a
README.md
file in the root folder. See this article for a good tutorial. Start with a short, user focused summary of the toolbox with installation instructions, and then point them to yourGettingStarted.mlx
file (see below). The rest of yourREADME.md
should be written for collaborators working on the toolbox, and how to contribute to it. It is a historical convention (more than 50 years!) that the file name be capitalized to make it stand out. - A
license.txt
file outlines how others can use, distribute, and change your code. Including a license file adds clarity and transparency for other people. Without a license, others may not be sure if they're allowed to use or change your code. - You should put images for your
README.md
file in animages
folder to reduce clutter. - See below for information on where to put tests, MATLAB projects, and automation files.
Our example toolbox starts with a README.md
with a single image, plus a license.txt
file.
arithmetic/
| README.md
| license.txt
└───images/
readmeImage.jpg
The toolbox folder is where you store all the materials that you plan to share with your users, including code, apps, and examples. Storing these materials in a single folder makes it clear what is going to be distributed to users, and what is not. The folder is named toolbox
and placed under the root folder.
The structure of your toolbox folder should reflect its size and complexity:
-
For projects with fewer than 20 functions or classes, put the documented functions that you expect users to call directly at the top level of the toolbox folder. Any helper functions or implementation details that users shouldn't access should go in a
private
subfolder. Functions and classes in this special folder are only accessible to code in its parent folder, keeping internal logic hidden. -
For larger projects, put the most commonly used functions and classes at the top level of the toolbox folder. Then, group additional specialized functions into folders by functionality. To keep things even more organized, consider using namespaces (see below) to organize your functions and classes into logical groups. Internal implementation code should be placed in a
<toolboxname>.internal
namespace. Functions in this namespace are callable with the full name, e.g.arithmetic.internal.intToWord
. While this code is callable by end users of your toolbox, the full name makes it clear that the code is not intended for end users.
We also recommend including in your toolbox folder:
- A
GettingStarted.mlx
file that introduces your users to your toolbox and showcase important workflows. This file should give an overview of how to use your toolbox and highlight key functionality. Put this file in adoc
folder under thetoolbox
folder. This specific name and location will come in handy later since it ensures your end users will be shown theGettingStarted.mlx
file when they install your toolbox. - Examples are an effective way for users to learn how to use your toolbox. We recommend using MATLAB Live Scripts to show how to use different parts of your toolbox and including them in an
examples
folder under the toolbox folder. This makes it easier for users to explore and try out different code samples.
Our example toolbox has:
- A
doc
folder with aGettingStarted.mlx
script. - A function for users called
add.m
. - An
examples
folder with MATLAB Live Scripts showing different ways the toolbox can be used. - A private function,
intToWord.m
that isn't intended for end users.
arithmetic/
:
└───toolbox/
| add.m
├───doc/
| GettingStarted.mlx
├───examples/
| usingAdd.mlx
└───private/
intToWord.m
MATLAB offers various features to make your toolbox more intuitive and user-friendly. We recommend the following to improve the quality of your toolbox:
-
Suggestions and Argument Validation: To enhance your user's experience when using your functions, you can add an
arguments
block to create customized tab completion suggestions. This was introduced in R2019a. Additionally, MATLAB will verify the type, size, and values passed to your function, enabling users to call your function correctly. See the Function Argument Validation documentation for more information. If you need more control over tab completion, create afunctionSignatures.json
and place it in the same folder as the corresponding function or class. See the custom suggestions and tab completion documentation for more information. -
Namespaces: Namespaces (also known as Packages) provide a means to organize classes and functions and reduce the risk of two functions having the same name. See the Namespaces documentation for more information.
-
MATLAB Apps: MATLAB Apps are interactive graphical applications that allow users to do specific workflows in your toolbox. You package your MATLAB App into a single file (.mlapp) for easier distribution. Create an
apps
folder at the top level of your toolbox folder. When you package your toolbox, make sure to include your apps in the toolbox packaging dialog's apps section. This way, the users can easily access and run your apps after installation. See the MATLAB apps documentation for more information.
Our example toolbox takes advantage of all these recommended features, providing a user-friendly experience:
- An app called
arithmetic.mlapp
in theapps
folder - Tab completion and argument validation for our functions
- The secondary functionality
describe.add
in thedescribe
namespace. These are grouped in the+describe
folder.
arithmetic/
:
└───toolbox/
| add.m
| functionSignatures.json
├───+describe/
| add.m
├───apps/
| arithmetic.mlapp
├───doc/
| GettingStarted.mlx
├───examples/
| usingAdd.mlx
├───private/
| └───intToWord.m
To successfully share your toolbox with others, having a release strategy is crucial. This will help you keep track of which version of your toolbox your users have and make bug reporting more efficient. Additionally, it will ensure that your users are equipped with a stable and well-functioning version of your code. By implementing a release strategy, you can have better control over the distribution of your toolbox and ensure the best experience for your users.
Sharing a MATLAB toolbox typically involves sharing a collection of .m files or combining them into a .zip file. However, we highly recommend a better approach - packaging your toolbox into a MATLAB Toolbox file (.mltbx
). This makes it easy for users to install and manage your toolbox. They can install by opening the .mltbx
file or using Add-Ons.
Note that the tools for packaging a toolbox changed in R2025a:
- Starting in R2025a, Toolbox packaging files are created using the Package Toolbox task with MATLAB Projects. Give the project file (with a
.prj
extension) the same name as the root folder. Put it in the root folder. - In releases prior to R2025a, toolbox packaging files are created using the Toolbox Packaging Tool. Confusingly, this file has a
.prj
extension -- the same as a MATLAB project file. These files are not interchangeable. Because of this, for releases prior to R2025a name your packaging filetoolboxPackaging.prj
and put it in the root folder.
Name your toolbox icon image file the same as your root folder (e.g. arithmetic.jpg
) and put it in the images
folder. The project files and toolbox icon image file should be under source control.
The MATLAB Toolbox file (.mltbx
) you create should be placed in a folder named release
under the root folder. Since this is a derived file, it should not be under source control.
For a full overview of toolbox packaging, see the Create and Share Toolboxes section of the documentation.
What to include: When you package, include all the contents in the toolbox folder, nothing else -- no exclusions, no extra stuff. Make sure that you include all your apps in the apps section of the packaging dialog.
Naming: Give a suitable name to your toolbox, this is the name users will see in the Add-on manager. It is recommended that you use spaces in the toolbox name to make it more readable. The MATLAB Toolbox file that gets created in the build process will have the same name. Note that GitHub.com does not allow spaces in files added to a release, so before you upload, you will have to change the filename to make spaces into underscores.
Version: Use semantic versioning. It helps your users plan and understand how much work they will have to do to update to your latest release. See the Semantic Versioning Standard for more information -- you really only need to read the summary. In the case of MATLAB, your "API" is the set of functions that your users use.
Our example toolbox has chosen to use the name “Arithmetic Toolbox”. This example is for R2025a and newer. For older releases, use toolboxPackaging.prj
instead of arithmetic.prj
.
arithmetic/
:
| arithmetic.prj
├───images/
│ readmeImage.jpg
│ arithmetic.jpg
├───release/
│ Arithmetic Toolbox.mltbx
└───toolbox/
add.m
:
Once a toolbox is packaged, there are multiple options to release your toolbox
- Create a GitHub release and link to MATLAB File Exchange. This lets you control what is delivered to users. Your toolbox will appear in the Add-on Explorer, and the latest released version will be installed. See this post for more info about how GitHub releases are shown in File Exchange.
- Create a GitHub source repository and link to MATLAB File Exchange. When you do this, your latest code in GitHub is always used.
- Post directly to MATLAB File Exchange
- Copy the MATLAB Toolbox file (
.mltbx
) to a shared location for your users. They can just double-click it to install it.
To help you ensure that your toolbox is high-quality, performant, and reliable, MATLAB has several features to help. We'll introduce you to the ones we think are critical for toolbox authors.
Tests check the quality of your toolbox and help you build confidence that you have high quality releases. The MATLAB Testing Framework provides support for testing your code. For users familiar with MATLAB, Function-Based Unit Tests will be the most familiar. Place your tests under the tests
folder in the root folder since tests are not usually shared with your users. If you host your toolbox on GitHub.com, you can use GitHub Actions created by MathWorks to qualify a change by automatically running the tests.
Here's what our example toolbox looks like with tests:
arithmetic/
:
├───tests/
| testAdd.m
| testIntToWord.m
└───toolbox/
add.m
:
- Projects are a great way to ensure a consistent environment for your authoring team. It manages dependencies in complex projects, keeps the path correct, and integrates with source control systems.
- Give the project file (with a
.prj
extension) the same name as the root folder. Put it in the root folder and check it into the source control system.
If we look at our example toolbox:
arithmetic/
| README.md
| arithmetic.prj
| license.txt
| toolboxPackaging.prj
:
└───resources/
- Source control systems should be set up with this folder as the root of a source repository. Additional configuration files like
.gitatributes
and.gitignore
belong in this folder. A.gitignore
file for a typical MATLAB toolbox project can be found here. - Scripts related to packaging and shipping the toolbox should be placed in a
buildUtilities
folder under the root folder. Consider using thebuildtool
introduced in R2022b. The tasks functions associated withbuildtool
are inbuildfile.m
.
arithmetic/
│ .gitattributes
│ .gitignore
| README.md
| arithmetic.prj
| buildfile.m
| license.txt
| toolboxPackaging.prj
├───.git/
:
├───resources/
└───buildUtilities/
For your toolbox project hosted on GitHub.com, MathWorks offers 2 badges you can use:
This opens your toolbox in MATLAB Online. This feature enables your users to try out your toolbox quickly. See this page to learn more and create an Open in MATLAB Online badge.
This provides an easy way for people visiting your GitHub repository to jump to your code on File Exchange. Once your File Exchange entry is set up, a tool will appear at the top of the page to assist you in creating a File Exchange badge. See this posting for more information.
Here are example repositories that apply some or all of these best practices:
Copyright © 2023 - 2025, The MathWorks, Inc.