I am trying to compile a list of file extensions that are accepted by GDAL, something like

['.tif', '.png', '.jpg', '.jpeg', ...]

I found a list of GDAL Raster file formats, but the values in the "code" column in that table are not always file extensions.

Is there a similar table that includes all filename extensions?

The goal is to check if GDAL can open a file from a path that is provided by users.

5 Answers 5


To get a list of format names and common extensions use:

from osgeo import gdal
for i in range(gdal.GetDriverCount()):
    drv = gdal.GetDriver(i)
    if drv.GetMetadataItem(gdal.DCAP_RASTER):
        print(drv.GetMetadataItem(gdal.DMD_LONGNAME), drv.GetMetadataItem(gdal.DMD_EXTENSIONS))

Output snippet:

('Virtual Raster', 'vrt')
('GeoTIFF', 'tif tiff')
('National Imagery Transmission Format', 'ntf')
('Raster Product Format TOC format', 'toc')
('ECRG TOC format', 'xml')
('Erdas Imagine Images (.img)', 'img')
('CEOS SAR Image', None)
('CEOS Image', None)
('JAXA PALSAR Product Reader (Level 1.1/1.5)', None)
('Ground-based SAR Applications Testbed File Format (.gff)', 'gff')
('ELAS', None)
('Arc/Info Binary Grid', None)

That is assuming you only want raster formats, and are using GDAL 2.0+. If you are using 1.x you can omit the DCAP_RASTER test. This is commonly used in 'Open...' or 'Save As...' dialogs for recommended names. If you are doing a 'Save As...', you have to check for the appropriate metadata option for Create() or CreateCopy()(DCAP_CREATE/DCAP_CREATECOPY).

Apologies if my code is non-pythonic, I rarely use it. If you'd like a specific answer for a specific version, please post your gdal version.

  • Your code is more or less fine. You're largely constrained by the GDAL API itself, so unless you plan to write wrapper code that follows the norms of the language a bit more (which for an application that would have to be maintained, I probably would), this is what you have to do. Even with the wrapper code, you're going to do something similar to this in the guts of it, anyway. The only thing I'd really advise changing would be to split the extension string on space, so you have a list of extensions. That would require testing for edge cases like None, though.
    – jpmc26
    Jan 6, 2016 at 3:37

File extensions are mostly meaningless. Sure, they might indicate the file's format but you can easily rename a .exe file to .txt and the file would not change itself. File extensions are mostly used for ease of usage and on some operating systems to decide what to do (which program to launch) if a user tries to "open" a file. Opening an .exe file that was renamed to .txt will lead to confusion because the file format itself is not text.

GDAL supports formats, not file extensions. Some formats have various common extensions, others might even not have any standards.

Instead of checking file extensions, use something like a try/except statement to determine if gdal can open the input file.

  • 1
    I am not sure if I agree that file extensions are completely meaningless, but you are right that they are not a reliable way of determining file types.
    – yellowcap
    Jan 5, 2016 at 15:22
  • aye, added some more sentences Jan 5, 2016 at 16:21
  • I agree that saying they're meaningless is going a bit far. What I would say is that they are a convention only, and that anyone and any software is free to violate the conventions.
    – jpmc26
    Jan 6, 2016 at 3:33

If you are trying to answer the question "Will the user be able to open the dataset with GDAL?" by comparing it to a precompiled list of file extensions (or even datasets for that matter) you will be in big trouble for two reasons:

  1. As @bugmenot123 pointed out the file extension might differ from the raster filetype and even more importantly a lot of extensions overlap / are used by different formats (e.g. .hdf, .bil).

  2. The amount of formats GDAL can handle depends largely on how it was compiled. Lots of drivers require external libraries to work and if GDAL wasn't compiled with them it won't be able to open the dataset (again .hdf HDF5 is a prominent example). There is no one definitive GDAL installation but it very likely differs from user to user.

One way to solve this is by trying to open the dataset and see if GDAL can handle it (as @bugmenot123 pointed out with try/except).

from osgeo import gdal
    print "not a supported dataset"

For those using the node-gdal bindings for Node.js:

const gdal = require('gdal');
const extensions = [];
gdal.drivers.forEach(driver => {
    const exts = driver.getMetadata().DMD_EXTENSIONS;
    if (exts) {
        exts.split(' ').forEach(ext => extensions.push(ext));

The GDAL raster format list already contains file extensions in the Long Format Name column. In the cases extensions aren't mentioned, it is because there are no defined extensions.

  • 1
    I believe the original poster is looking for a spreadsheet or listing of extensions themselves that can be consumed by a script. For example, Arc/Info ASCII Grid does not have any reference to it's actual extension (.asc) in that document.
    – MaryBeth
    Jan 5, 2016 at 19:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.