toastification: Flutter toasts that queue instead of overlapping

A queue for toasts, which is the feature the name hides

Toastification is a Flutter package for displaying customizable toast messages, providing predefined widgets for success, error, warning and info messages, as well as a custom widget for flexibility, and the ability to add and manage multiple toast messages at the same time.

The explanation of what that means in practice is the sentence worth reading twice. Developers can display multiple toast notifications at once and display them in a queue, which means that if multiple notifications are triggered at the same time they are displayed one after the other rather than overlapping on the screen.

That is the whole reason to reach for a package rather than using the SnackBar that Flutter already ships with. A snackbar replaces the previous one, so a form that validates two fields, or an app that fires an error while a success is still on screen, loses messages. A queue does not.

The rest of the package is the presentation layer around that behaviour. Toast messages are described as a type of pop-up message that typically appears on the screen and disappears after a short amount of time, used for information, alerts or confirmations, and the README is candid about the value proposition, that it saves you writing the code from scratch.

The project is BSD-3-Clause licensed, the primary language is Dart, the homepage is payamzahedi.com/toastification, and the last push to the repository was on 2026-04-19 with the v3.2.0 release on the same day, following v3.1.0 on 2026-04-12 and v3.0.2 on 2025-03-12.

Five predefined styles, each with a stated purpose

The styles are the part of the API that decides whether the package fits your design, so the README's descriptions are more useful than the enum names alone.

ToastificationStyle.flat is described as a simple and clean style with a subtle border and no background fill, ideal for minimalist notifications that do not overwhelm the interface.

ToastificationStyle.fillColored is a bold style with a solid colored background, for high visibility alerts or important notifications that need immediate attention.

ToastificationStyle.flatColored is a balanced style with a flat design, colored borders and text but without a solid fill, for notifications that need to stand out without being too bold.

ToastificationStyle.minimal is a sleek and modern design with minimal elements and an accent line denoting the notification type, for clean and distraction free interfaces.

ToastificationStyle.simple is a straightforward style showing a single line of text, best for short simple messages or confirmations where minimal design is preferred.

Two things stand out. The accent line in the minimal style carries the type information, so the type survives a design that has no colour coding, which is the kind of detail that matters for accessibility. And the simple style is a single line of text, which tells you the package can cover the small confirmations where a snackbar would have been enough, without a second dependency in those parts of your app.

The five styles are selected with the ToastificationStyle enum, and the message category with the ToastificationType enum, in the show method.

show and showCustom are the two halves of the API

The usage section names the two entry points before it explains anything else. The toastification.show method shows predefined toast messages with predefined styles, and the toastification.showCustom method shows custom toast messages with custom styles.

Both are reached either through the toastification instance or through the Toastification() constructor, so the package works as a singleton or as an object you own, which matters if you are testing and want a fresh instance per test.

The predefined path is short.

toastification.show(
  context: context, // optional if you use ToastificationWrapper
  title: Text('Hello, world!'),
  autoCloseDuration: const Duration(seconds: 5),
);

A type and a style pick the look, and the rest of the parameters tune it.

toastification.show(
  context: context, // optional if you use ToastificationWrapper
  type: ToastificationType.success,
  style: ToastificationStyle.flat,
  autoCloseDuration: const Duration(seconds: 5),
  title: Text('Hello, World!'),
);

The custom path takes a widget you build yourself, and the parameters that control behaviour, such as the alignment, the animation and the close button, are available there too.

So the design is a sensible one. The common case is a type and a style, and the unusual case is a widget, and the behavioural parameters are shared between them rather than being split across two unrelated APIs.

ToastificationWrapper is how you drop the context requirement

There is a section on usage without context, and it is short because the solution is a wrapper.

If you want to display toast messages without using context, wrap your AppWidget with ToastificationWrapper.

return ToastificationWrapper(
  child: MaterialApp(),
);

And now you can use both toastification.show and toastification.showCustom without providing context.

The context parameter is marked as optional in the show examples with a comment saying it is optional if you use ToastificationWrapper, so the wrapper is the mechanism that makes the parameter optional rather than a separate call style.

The reason this matters is that a context is awkward to obtain in exactly the places where a toast is most useful: in a service class, in a repository callback, in an error handler that has no widget above it. Passing a context down to those layers is the sort of dependency that quietly spreads through a codebase.

The trade-off is that the wrapper becomes a structural requirement of your app. It sits above MaterialApp, so it has to be there from the first line of main, and if you add the package later to an existing app, that is the change you have to make.

The parameter list is where the real control lives

The long show example in the README is essentially a catalogue of everything the package can do, and reading it is the fastest way to decide whether it fits.

Beyond type, style and title, the parameters cover the content itself with a description that can be a RichText widget as well as the title, the placement with alignment and textDirection, the entry and exit behaviour with animationDuration and an animationBuilder that receives the animation, the alignment and the child, and the icon with a showIcon flag to hide it.

The visual parameters are ordinary Flutter widgets, which is the right choice. primaryColor, backgroundColor and foregroundColor, padding and margin, borderRadius, and a boxShadow with colour, blur, offset and spread. The shadow in the example uses a very low alpha black with a 16 pixel blur and a 16 pixel vertical offset, which is the conventional trick for a soft shadow without a visible border.

The behaviour parameters are the more interesting group. autoCloseDuration sets how long the toast stays. showProgressBar draws a progress indicator across the toast, so the user can see how long is left. closeButton takes a ToastCloseButton with a CloseButtonShowType, and the example uses onHover, meaning the close control appears when the pointer is over the toast. closeOnClick decides whether tapping the toast dismisses it, pauseOnHover keeps the toast alive while the pointer rests on it, dragToClose lets the user swipe it away, and applyBlurEffect blurs what is behind the toast.

The callbacks are the fourth group, and they are where a toast stops being decoration and becomes a reporting channel. ToastificationCallbacks takes onTap, onCloseButtonTap, onAutoCompleteCompleted and onDismissed, and each receives the toast item, whose id you can use to correlate a dismissal with the action that triggered it.

The Toast Builder writes the call for you

There is a section of the README before the installation instructions, and it points at a tool rather than at code.

The Toast Builder Website is described as the way to customize your toast notifications, copy the generated code and integrate them into your project, and the README calls it the quickest way to get started if you do not want to read the whole documentation.

That is a sensible division of the work. The parameter list is long, and the first time you use a package like this you mostly want to see the shape of a call and then adjust it. A visual builder that emits the code gets you a working toast in a couple of minutes, and the result is still ordinary Dart that you can then edit by hand, which matters because generated code you cannot read is generated code you cannot debug.

The site lives at payamzahedi.com/toastification, alongside the package documentation, and the repository carries a doc directory with the images the README uses, an example directory that is a full Flutter app with android, ios and web targets, and a test directory.

The example app is worth a look before you install anything, because it tells you what the package looks like inside a real project rather than in isolation, and the tests tell you what the maintainer considered worth checking. The repository also carries a .fvmrc, which pins the Flutter SDK version the project is developed against, plus an analysis_options.yaml for the linter and a codecov.yml for coverage reporting.

Editorial conclusion

toastification suits a Flutter team that needs more than one message on screen at a time, because the queue behaviour and the set of built in styles solve the problem that a plain snackbar cannot, and the parameter surface covers alignment, animation, progress bar, close button, drag to close and hover behaviour without writing that code. It does not suit a project that only needs a single confirmation message, where a SnackBar is shorter and has no extra dependency, and it does not suit a team that cannot accept a package with a large parameter list. Before you adopt it, check the version you take against your Flutter SDK constraints, since the last push to the repository was on 2026-04-19 and the newest release is v3.2.0 from the same day, and read the ToastificationWrapper section if you show toasts from code that has no BuildContext, because that is the one structural decision the package asks you to make up front.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. payam-zahedi/toastification on GitHub
3. Project website
4. README
5. Releases