Kodi add-on structure

This page summarizes the Kodi add-on structure  system introduced in the Dharma release (v10) of XBMC. This system allows third-party developed enhancements to Kodi to be distributed to Kodi users directly from inside the Kodi interface.

The add-ons system is based on the plugin library c-pluff.

1 Introduction

Each add-on is kept in its own folder, and is described via an XML file named addon.xml. In addition, some other files can also come with the add-on, such as icon.pngchangelog.txt, and fanart.jpg. These are all optional, though we encourage you to at least have icon.png. All of these reside in the “root” of the folder that contains the add-on. Additional data may be contained within a resources/ subfolder, such as language translations and descriptions of settings.

When installed, the whole add-on folder will be placed inside .xbmc/addons/.

2 Directory Name

Your directory name should follow this convention:


Each name part is case sensitive and must be in lower case. The dot character separates each name part; you can use further dots to separate things in your plugin name if you wish. Alternatively, you may use a hyphen (-). No other non-alphanumeric characters should be used.

addon-type is one of the following:


Add-on Type Description Media Type Required?
repository A repository definition file that allows users to add new repositories to the Kodi addon manager. No
plugin A plugin script or module that adds to the functionality of Kodi. Plugins appear under the relevant media section of the main home menu. Yes
script A runnable program file that will appear in the Program section of the main home menu. Yes
skin An Kodi skin definition and its supporting script files. No
resource An addon that will provide additional files (language files, images, uisounds). No


The following table describes the available media-types for the available add-on types. Your add-on may provide more than one media-type if you wish, whereby it will appear in more than one section. In most cases, however, a single media type will suffice, and it may be preferable to have multiple add-ons each providing a single media type rather than one add-on that tries to do it all.


Add-on Type Media Type Description
plugin audio A music add-on that will appear in the Music main menu.
plugin video A video add-on that will appear in the Video main menu.
plugin picture A picture add-on that will appear in the Pictures main menu.
plugin program A program add-on that will appear in the Add-ons main menu.
plugin weather A weather add-on that will appear in the Weather main menu. You can omit the Add-on Type in the directory name and addon-id
script module A script plugin that will not appear under a category or within the Add-ons manager, but provides support for other add-ons.
script service A script that will be run at either login or startup


The add-on name is up to you, but be sure that it isn’t already in use by another add-on. For instance, if you are creating an add-on that integrates the Gpodder software with Kodi for audio podcasts you might name your directory plugin.audio.gpodder-xbmc3. If you are creating a screen scraper to present TV shows from MyGreatTv.com. It might be plugin.video.my-great-tv-com. A script to ping all your friends on twitter to tell them you are home might be called script.service.ping-twits-i-am-home.

3 Directory structure

Your directory contains all the resources needed to operate your add-on. The directory must be considered read-only and should not be used for storing transient or inter-session data. Other mechanisms are available to do that (more later). The directory should be structured as follows:

3.1 Kodi v17 Krypton and up


3.2 Kodi v16 Jarvis and earlier


Other files may be required to run your add-on, if your add-on becomes more complex. It is considered good practice to place various add-on resources and support code modules in the lib/ folder. If those libs are commonly used by multiple add-ons, consider adding them as a separate add-on, e.g. script.module.foo.

The most important thing to remember from this is that everything that doesn’t need to be in the root of your directory is considered a resource and should be placed inside resources/ or one of its subdirectories. Also remember, all the above is a recommended outline for your add-on; if you need fewer or more directories to organise your work, just change it. For instance, skins are add-ons that will require more directories than this.

3.3 addon.py

This will contain the main Python code for your add-on. You can name it whatever you want, since you’ll define this Python file in addon.xml as your main script file.

3.4 addon.xml

addon.xml gives Kodi important metadata about your add-on, such as:

  • what the add-on provides
  • what the add-on relies on to work
  • what script to run when it is fired up (if it is meant to be started)

3.5 changelog.txt

Note: Deprecated in Kodi v17 Krypton. Replaced by Addon.xml#.3Cnews.3E

A text file that contains a description of the changes you make to the add-on for each release. This is displayed in the Kodi addon installation/update system. The recommended format is to have it sorted by version in descending order, with a simple description as to the major changes (new functionality, big fixes, etc) in each version. (In the author’s opinion, too many add-ons skip this piece of information, making it difficult for users to determine whether a particular problem that they may have been having has been fixed or not.)

Here is a sample changelog.txt:

v0.1.3 (2015-12-25)
- Update with 15.0 Isengard

v0.1.2  (2014-1-15)
- Add notification for Ubuntu users checking through apt command

v0.1.1  (2014-1-1)
- Initial version

It is recommend to add a date so users know when last update was done. Best is to use YYYY-MM-DD as this is the least confusing way of dat notation.

3.6 icon.png

This is an icon used to represent your add-on in various parts of Kodi. In order to keep a coherent look and give the skinner a good idea how the icons of the add-ons look, we have defined the following rules:

  • The icon size must be 256×256 pixels or 512×512 pixels.
  • File format is PNG.
  • Background must be 100% solid. That doesn’t mean one color, it also can be a gradient or a low contrast texture. Just make sure there is no transparency.
  • Keep the logo as simple a possible, no exaggerated 3D effects or high contrast textures.
  • Use a padding of at least 25px for your logo (not the background!). Excepted are large text logos (see icon for themoviedb.org).
  • Keep text to a minimum. However, a text logo along with the graphical logo is recommended in order to easily recognize the addon.
  • Don’t mix logos with Kodi’s logo; it’s obvious that we’re talking about Kodi here.
  • Don’t add borders or any overlays, that’s the skinner’s job. However, if borders are an element of your logo, make sure there is enough padding.
  • It is suggested that a logo on a plain background (non-transparent) is best in many situations (e.g. for addons that retrieve media from an online service, use that service’s logo as long as you are free to do so).
  • Note: Kodi v17 Krypton and later if this file exists, “icon” must be listed in addon.xml assets

3.7 fanart.jpg

This helps to keep Kodi graphically rich when browsing and using add-ons. Some simple guidelines:

  • It should be 16:9 aspect ratio
  • It is intended for the background, so should be simple and without text where reasonable.
  • We recommend a 1280×720 JPEG image. It should certainly be no larger than 1920×1080.
  • We recommend keeping it as small as is reasonable with respect to file-size. Remember that hundreds of thousands of users are going to be downloading this.
  • Note: Kodi v17 Krypton and later if this file exists, “fanart” must be listed in addon.xml assets

3.8 LICENSE.txt

This file should contain the text of whatever software license you’ve chosen to release your add-on under (e.g. GPLv2).

3.9 resources/

The resources/ subdirectory is the preferred place to put any files that the add-on uses that don’t need to be stored in the root directory. For instance, translations, software libraries, and image resources would go in resources/ or one of its subdirectories.

3.9.1 resources/settings.xml

This is an XML file that defines the user-configurable settings used by the add-on. The file defines the names and types of the settings, and how they should appear in the settings dialog for the add-on.

3.9.2 resources/language/

Translation tools:

String ID range:

  • strings 31000 thru 31999 reserved for skins


Note: strings.xml will possibly be deprecated after the release of Frodo/Gotham. Frodo and Gotham will still be backwards compatible with .xml

3.9.3 resources/lib/

Put any module definitions or third party software libraries into this directory.

3.9.4 resources/data/

Store any other static data structures your application requires here. Examples might be XLT/XSD files or static XML files that contain lookup tables etc.

3.9.5 resources/media/

Store any static media (picture, audio, video etc.) files in this directory.

4 Getting started

Following pages will explain in more depth to get started. Providing examples, background information and useful links.

5 See also


Connected through code, Choose Your Platform!

About the Author: Bernard Aybout

In the land of bytes and bits, a father of three sits, With a heart for tech and coding kits, in IT he never quits. At Magna's door, he took his stance, in Canada's wide expanse, At Karmax Heavy Stamping - Cosma's dance, he gave his career a chance. With a passion deep for teaching code, to the young minds he showed, The path where digital seeds are sowed, in critical thinking mode. But alas, not all was bright and fair, at Magna's lair, oh despair, Harassment, intimidation, a chilling air, made the workplace hard to bear. Management's maze and morale's dip, made our hero's spirit flip, In a demoralizing grip, his well-being began to slip. So he bid adieu to Magna's scene, from the division not so serene, Yet in tech, his interest keen, continues to inspire and convene.