Feature flags and toggles sometimes get used interchangeably, but they don't exactly mean the same thing. While feature toggles and feature flags started with similar goals, they've evolved in some interesting ways. And knowing the difference gives you more control over your releases (and your semantics).

Below, we'll walk you through everything you need to know about feature flags vs. feature toggles, including: what they are, how they work, and how they differ.

What is a feature toggle?

A feature toggle is a software development technique that lets developers turn specific functionalities of an application on or off. Think of it as a switch in your code that controls whether a particular feature is available to users or not.

Here's how it works:

1. Developers wrap a new feature or code change in a conditional statement.
2. This conditional statement checks the state of the toggle (on or off).
3. Based on the toggle's state, the feature is either executed or skipped.

Feature toggles were initially introduced to solve a common problem in software development: how to release new code without disrupting the entire system. They allow teams to:

• Deploy code to production without immediately activating new features
• Gradually roll out features to specific user groups
• Quickly disable problematic features without rolling back the entire deployment

For example, imagine you're adding a new search function to your e-commerce site. With a feature toggle, you could:

if feature_toggle.is_active('new_search'):
    # Code for the new search feature
else:
    # Code for the old search featureCopied!

While feature toggles started as simple on/off switches, they laid the groundwork for more advanced feature management techniques. As we'll see, this evolution led to the development of what we now often call feature flags.

How are feature flags different from feature toggles?

Although feature toggles and feature flags are used quite interchangeably today, feature flags may be growing into the more appropriate term. At LaunchDarkly, we view toggles as a subset of feature flags and feature management.

A toggle or switch implies that something has two states: on and off. Feature management on the other hand includes choosing how your code behaves in the moment, providing far more fine-grained control over your experimentation and feature rollouts.  

When Martin Fowler published Patterns for Managing Source Code Branches in 2020 on feature branching, the term feature flag was used rather than feature toggle as a way to hide a partially built feature. 

If there’s no way to easily hide the partial feature, we can use feature flags. As well as hiding a partially built feature, such flags also allow the feature to be selectively revealed to a subset of users—often handy for a slow roll-out of a new feature.

Many new frameworks are switching to the nomenclature of flag because they support long-term control, percentage rollouts, and multivariate states.

Feature flags vs. feature toggles

While feature flags and feature toggles share common roots, they've developed distinct characteristics.

Feature toggles

Pros:

• Simple to implement and understand
• Lightweight, with minimal impact on performance
• Useful for basic on/off functionality
• Can be easily managed with simple configuration files

Cons:

• Limited functionality beyond on/off states
• Can lead to code complexity if overused
• May require more custom code for advanced use cases
• Typically require developer involvement for changes

Feature flags

Pros:

• Offer more granular control over feature rollouts
• Support complex scenarios like A/B testing and canary releases
• Often come with user-friendly interfaces for non-technical users
• Provide analytics and monitoring capabilities
• Better suited for long-term feature management

Cons:

• May require integration with third-party tools or services
• Can be more complex to set up initially
• Might have a slight performance overhead due to additional logic
• May incur costs if using a commercial feature flagging service

Feature flags use cases

Below are two use cases where a flag is a more appropriate description than a toggle, particularly in the context of enabling DevOps.

Use case 1: A/B testing

Feature flags do not have to be binary, and often are not. With an A/B test, you typically present two variations, but a flag can return multiple values with A/B/N testing: variations like blue, red, green, and purple, which your code can interpret to display different variants of a feature. You could also potentially use flags to release new features using date ranges and numbers. In other words, the feature itself can have more than two states, and these states do not necessarily need to be on or off. The off variation for a feature flag could hide the code changes completely, whereas the blue or red variations will serve different variants. A/B testing is also an example of where people outside of the development team can make use of feature flags. Product managers for instance may use A/B testing to understand how features resonate with their user base and make data-driven decisions to improve user experience.

Use case 2: canary releases

A canary release refers to sharing a feature or a set of features with a subset of users. Canary releases help you minimize risk by having a trusted group of users access a new feature before rolling it out to a wider, higher-risk audience. Feature flags help you precisely identify and judge whether a user has the right level of permissions to see the requested information. Rollbacks, where necessary, are contained to a smaller subset of the user base, so teams can work on debugging problematic new code as soon as possible.

Canary releases differ from A/B testing in that the latter is usually used to understand how users respond to a new feature or code change, whereas canary releases can be used to conduct testing on backend functionality in addition to user-facing features.

Beyond canary releases and incremental rollouts, testing in your production environment is a powerful way to understand the impact of code changes.

A feature flag can be considered a way to manage the full lifecycle of a feature, tracking the progress of a feature from development, to QA, and to production. It can also be a way for you to aggregate performance analytics and metrics and test the impact of a feature on your system’s architecture.

Looking forward

There is no wrong way to categorize a feature toggle or feature flag. What is important is that companies are starting to realize the importance of separating feature rollout from code deployment. This separation enables software to be more adaptive to user needs while also contributing to platform stability.

The spectrum of options available with feature flagging helps to enable progressive delivery. Progressive delivery builds upon the practice of continuous integration and continuous delivery (CI/CD) with robust use of feature flagging and observability to ship code safely and fast. 

The future of software development and continuous delivery highlights the significance of feature release management. A feature release is now no longer an afterthought. It is something that must be built into the development of a feature from its inception to its rollout. Planning a feature release should be integrated into a development team’s workflow.

Feature flag management is critical for effective feature flagging at scale

With feature flags having more advanced functionality than simple on/off or release toggles, the potential for technical debt grows. If you’re just starting out with feature flags, a config file may suffice. As the number of flags and complexity of your configurations increases, outdated or duplicative flags can accumulate quickly in your codebase. Having a robust feature flag management solution helps to keep tech debt associated with flags in check by allowing teams to manage them from one central location.

Feature flags and toggles are not just a best practice for the continuous delivery of software, but are now becoming integral to running a business. With the right feature management platform you can safely test new code to get real feedback and iterate quickly.