This page describes the development and management of Plugins for use with the Unreal Engine tools and runtime.

Many Unreal Engine subsystems were designed to be extensible, allowing you to add entire new features and to modify built-in functionality without modifying Engine code directly. You can create new file types, add new menu items and tool bar commands to the Editor, or even create entire new features and Editor sub-modes!

If you want to jump right in and try out plugins now, please see the Plugin Examples section.

Plugins Editor UI

You can see which Plugins are currently installed by opening the Plugin editing interface from the Edit menu.


The Plugin Editor is accessible from the main 'Window' menu. This interface displays all of the Plugins that are currently installed and can enable or disable Plugins individually.

You can browse categories of Plugins using the tree interface on the left. Selecting a category will show all Plugins in that category as well as Plugins in any sub-category. As you navigate through categories, a bread crumb trail displayed at the top of the UI will enable you to jump quickly to higher-level categories. The number displayed next to a category indicates how many Plugins are available in that category.


Plugins are displayed in the main list, along with each Plugin's name, icon, current version, text description, author (and optional web hyperlink), as well as whether or not the plugin is currently enabled.

The search control at the top will enable you to search Plugins displayed in the list by name.


You can enable or disable a Plugin for use with your active project by toggling the Enable check box under the Plugin's description. You may need to restart the Editor for the change to take effect.

Anatomy of a Plugin

Plugins with code will have a Source folder. This folder will contain one or more directories with module source code for the Plugin. Note that, although Plugins often contain code, this is not actually a requirement. See the Code in Plugins section for more information.

Plugins with code will have a Binaries folder that contains compiled code for that Plugin, and temporary build product files will be stored in a seprate Intermediate folder under the Plugin's directory.

Plugins can have their own Content folder that contains Asset files specific to that Plugin. See the Content in Plugins section for more information. Plugin config files should be placed using the same convention as other config files:

  • Engine plugins: [PluginName]/Config/Base[PluginName].ini
  • Game plugins: [PluginName]/Config/Default[PluginName].ini

Plugins do not yet support their own Derived Data Cache distribution. We plan to add support for this at a later date.

Plugin Folders

In order for Plugins to be found, they must be located in one of the valid search paths for Plugins, either in your project, or in the Engine itself.

Plugin Type

Search Path


/[UE4 Root]/Engine/Plugins/[Plugin Name]/


/[Project Root]/Plugins/[Plugin Name]/

You can also organize Plugins into subdirectories under the base Plugins folder. The engine will scan all of your sub-folders under the base Plugins folder for Plugins to load, but it will never scan into subdirectories beneath a Plugin that has already been found.

The Unreal Engine finds your Plugin by searching for .uplugin files on disk. We call these files Plugin Descriptors. They are text files that provide basic information about your Plugin. Plugin Descriptors are discovered and loaded automatically by the Engine, Editor, and the Unreal Build Tool (UBT), whenever those programs are run. See the section on Plugin Descriptors to learn about creating and customizing these files.

Code in Plugins

When generating project files for Visual Studio or Xcode, any Plugins that have Source folders (containing .Build.cs files) will be added to your project files to make it easier to navigate to their source code. These Plugins will automatically be compiled by UBT when compiling your game project.

Plugins are allowed to have any number of Module source directories. Most Plugins will only have one Module, but it is possible to create multiple, for example, if a Plugin contains some Editor-only functionality, and other code that is intended to run during the game.

For the most part, Plugin source file layout is the same as any other C++ Module in the Engine.

Plugins are able to declare new UObject types (UCLASSUSTRUCT, etc.) in header files within a Classes subdirectory in their Module code folders. The Engine's build system will detect these files and generate code as needed to support the new UObject types. You will need to follow the normal rules for using UObjects within C++ modules, such as including the generated header file and the Module's generated.inl file in one of your Module's source files.

Most Plugin Modules will not export public APIs in header files via the Public source folder, because Plugin Modules cannot be direct dependencies (or statically linked) by the Engine or by game code. However, there are a few exceptions to this rule:

  • If your Plugin contains multiple C++ Modules, code in a Public folder can be shared between Modules within your Plugin.
  • If you are creating a game Plugin (not an Engine Plugin), and you want the game to statically link against one of your Plugin Modules. This is an unusual practice, but can be often useful for Plugins that want to declare new UObject types that game classes can inherit or use directly. The Engine itself will never have direct dependencies on a Plugin, but the game project code and content may.
  • If you want to distribute public interface headers with your Plugin in order to enable game code or other Plugins to access types implemented in that Plugin's Modules. This is very uncommon and generally discouraged, as we do not currently intend to support Plugins that are directly dependent on other Plugins.

Content in Plugins

Unreal Engine supports plugins that contain Content as well as binary code. In order to use Content in a Plugin, the "CanContainContent" setting within the Plugin's descriptor must be set to "true".

Plugins in your Game Project

Plugins reside under the Plugins subfolder within your project's directory, and will be detected and loaded at Engine or Editor startup time.

If the Plugin contains modules that have Source folders (and .Build.cs files), Plugin code will automatically be added to generated C++ project files, so that you can work on developing the Plugin alongside your project easily. Whenever you compile your project, any Plugins that have source available will also be compiled as a dependency of your game.

Plugins that do not have a Source folder are ignored by the project generator and will not appear in your C++ project files, but they will still be loaded at startup as long as binary files exist.

Engine Plugins

Unreal Engine 4 has some built-in Plugins included under the Engine directory. Engine Plugins are just like project Plugins, except that they are available for all projects. Typically, these plugins are created by engine and tools programmers to provide baseline functionality that can be used in multiple projects while being maintained in a single place. This can enable the user to add or override engine features without modifying engine code.

By default, engine Plugins are loaded before any of the project's Plugins or Modules are loaded.

Engine Plugins have a special requirement: Engine Modules must never statically link against Plugin Module libraries. That is, engine Plugins must remain compartmentalized from the Engine itself; Plugin Modules must never be "dependency modules" for Engine Modules. This is a philosophical choice that allows the Engine to function even when the Plugins are not available to be loaded.

Distributing a Plugin

Here are the steps required to distribute a plugin.

  1. Make sure the modules list in your .uplugin file has a correct list of whitelisted and blacklisted platforms.
  2. Find your plugin in the editor's plugin browser, and click the 'Edit...' link to update the metadata associated with your plugin (description, link to documentation, and so on).
  3. Click the '**Package...*' link to package your plugin into a folder for distribution.

By default, only source code, binaries and content will be packaged with your plugin. If you have additional files you need to include, create a file called Config/FilterPlugin.ini in your plugin folder which lists additional paths to include, like this:


Important notes:

  • For plugins with Content, you may want to generate Derived Data to include with your plugin, to avoid requiring it to be generated on-demand by an end user. This feature is not yet available, but will be added at a later date.
  • Including an end-user license agreement (EULA) or other documentation with distributed plugins is not yet supported. We may provide support for this at a later date.

Plugin Descriptor files

Plugin descriptors are files that end with .uplugin. The first part of the file name is always the name of your Plugin. Plugin descriptor files are always located in your Plugin's directory, where the Engine will discover them at startup time.

Plugin descriptors are in the Json (JavaScript Object Notation ) file format.

Descriptor File Example

This example plugin descriptor is from the UObjectPlugin example above.

    "FileVersion" : 3,
    "Version" : 1,
    "VersionName" : "1.0",
    "FriendlyName" : "UObject Example Plugin",
    "Description" : "An example of a plugin which declares its own UObject type.  This can be used as a starting point when creating your own plugin.",
    "Category" : "Examples",
    "CreatedBy" : "Epic Games, Inc.",
    "CreatedByURL" : "",
    "DocsURL" : "",
    "MarketplaceURL" : "",
    "SupportURL" : "",
    "EnabledByDefault" : true,
    "CanContainContent" : false,
    "IsBetaVersion" : false,
    "Installed" : false,
    "Modules" :
            "Name" : "UObjectPlugin",
            "Type" : "Developer",
            "LoadingPhase" : "Default"

Descriptor File Format

Field name





Version of this Plugin descriptor file. Note that this really is the descriptor file version, not the Plugin version. This is used for backwards compatibility as new features are added to the Plugin system, and should usually set to the highest version that is allowed by the Engine. The latest version is currently 3, and is the version documented here. We do not expect this version to change very frequently. In the source code, you can look up the EProjectDescriptorVersion namespace and read through the enumerated values to check the actual value. If you require maximum compatibility with older versions of the engine, then you can use an older version of the format, but it is not recommended.



Current version number of this build of your Plugin. This value should always increase with future versions. This version number is not intended to be displayed to end users.



Version of the plugin displayed in the Editor. This is not the actual version number as far as the Engine and Editor are concerned, and is used for version checks. This can be in whatever format you prefer, although a simple "Major.Minor" format is usually used.



The name of the Plugin that will be displayed in the Editor. If not specified, the name will default to the .uplugin file name.



A paragraph of text that describes what this Plugin is used for. This will be displayed in the Editor's Plugin window.



This is a special dot-separated path string that allows you to assign your Plugin to a category in the Editor's Plugin UI. This field is purely for organizational purposes. An example of a category path is "Editor Features.Level Editing.Mesh Painting". Each category is separated by a period character and represents a deeper level in the tree.



The individual or company name that created this Plugin. This may be displayed in the Editor's Plugin UI or in other locations.



A web link to the individual or company that created this Plugin. Will be shown on the Editor's Plugin browser if specified.



A web link to the Plugin's documentation. Will be shown on the Editor's Plugin browser if specified.



A link to the plugin's Marketplace page. Will be shown on the Editor's Plugin browser if specified.



Link to the support page for the plugin. Will be shown on the Editor's Plugin browser if specified.



If set to true, this plugin will be enabled by default when it is present.



When specified and set to true, enables content support for this Plugin. The default setting is false. See the section on Content in Pluginsfor more info.



Marks the Plugin as a beta version. In the list of Plugins, "Version" will be replaced with "BETA Version" for this Plugin.



If set to true, the Plugin will be listed under the "Installed" section in the list of Plugins, instead of the "Project" or "Built-in" sections.



For Plugins that contain source code (and binaries), this is the list of Modules that should be loaded at startup. See below for more information.

Module Descriptors

For Plugins that contain code, the descriptor file will contain at least one Module descriptor.

    "Name" : "UObjectPlugin",
    "Type" : "Developer"
    "LoadingPhase" : "Default"

Field name





Unique name of this Plugin Module that will be loaded with the Plugin. At runtime, the Engine will expect appropriate Plugin binaries to exist in the Plugin's Binaries folder with the Module name as specified here. For Modules that have a Source directory, a matching .Build.cs file is expected to exist within the Module's subfolder tree.



Sets the type of Module. Valid options are RuntimeRuntimeNoCommandletDeveloperEditorEditorNoCommandlet, and Program. This determines which types of applications will load this Module. For example, the "Editor" option will cause a Module to load only in the Editor, meaning it will not load in a shipped product and should not be used for any in-game behaviors. It is supported for a Plugin to contain multiple Modules of different types.



If specified, controls when during startup the Plugin will be loaded. This is an advanced option that should not normally be required. The valid options are Default (which is used when no LoadingPhase is specified), PreDefault, and PostConfigInitPostConfigInitallows the Module to be loaded before the Engine has finished starting up key subsystems. PreDefault loads just before the normal phase. Typically, this is only needed if you expect Modules to depend directly on content within your Plugin, or on types declared within your Plugin's code.



If specified, gives a list of platforms which this Module will be compiled for. If not specified, the Module will be compiled for all platforms.



If specified, gives a list of platforms which this Module will not be compiled for. If not specified, the Module will be compiled for all platforms.

Icon Files

Along with the descriptor file, Plugins usually have an icon file that is used when displaying the Plugin in the Editor's Plugin list.

File name






128x128 PNG file

This icon represents this Plugin in the Editor's Plugin list. It will be displayed in the 'Plugins' user interface accessible from the main Window menu.

Plugin Examples

We have created a few example Plugins that do not really do anything, but serve as an empty shell that you can use when starting to create your own Plugin. These are included with the Engine source code.

Example name



This Plugin is an empty shell that shows the bare minimal files needed to setup a new code Plugin Module.


A simple empty Plugin that demonstrates how to declare your own UObject class.

To use these examples as a starting point for your Plugin:

  1. Copy an example Plugin to a new folder and rename the directories, files and code contents to match your new Plugin name. Leaving the existing names will cause collisions with the original Plugin.
  2. **Make a Plugins folder** under your project directory, then copy your Plugin to any subdirectory under Plugins.ExamplePlugins.png
  3. Rebuild your C++ project files. The Plugin Modules and source code will appear in directories under your project's directory in the project file.
  4. Compile your project normally. Unreal Build Tool will detect the Plugins and compile them as dependencies to your project.
  5. Launch the Editor. Your Plugin will be disabled initially, but you can enable it Editor's Plugin list.
  6. Open the Plugins list within the Editor (Window -> Plugins), and search for your Plugin. Enable it by clicking the check box.
  7. Restart the Editor. Your Plugin will be loaded automatically at startup.
  8. You can see that the Plugins have loaded by opening the Modules viewer under the Window -> Developer Tools menu. You can also use your code debugger to place a breakpoint in the Plugin's startup code, such as the StartupModule function.