Is there a "standard" file suffix for modern Fortran code?

As you all know, Fortran changed over the years, and it’s still changing. For years, I used *.f as a file name convention for Fortran code, then *.f90, then *.f03, *.f08, and so on. I thought such a naming convention was a convenient way to tell which standard (-std=…) the code follows, without looking at the corresponding Makefile(s). However, this also means I have to rename a program that used, e,g, the Fortran 2003 standard but now uses Fortran 2008 (because I added F08 functionality in it.) It quickly becomes a headache, so I would like to just settle with a “standard” naming convention - if there is such a thing.

From what I gathered looking it up, *.f90 seems to be the de facto “standard” - which makes sense, given Fortran 90 was the “quantum leap” in Fortran history, leading the language to what I consider Modern Fortran. However, one could argue that *.f03 might be a better choice, since Fortran 2003 adds significantly more features, most notably object-oriented programming. So my question is… is there any standard, official file naming convention for Fortran programs, or it’s still a “name them however you like” El Dorado?


The Fortran 90 standard introduced free source form, and all compilers assume that .f90 code is free source form, so use the .f90 suffix. Your own post explains why .f03 etc. is inadvisable. When I see a new Fortran project on GitHub that uses .f95 .f03 etc. I raise an issue with the form letter below. In most cases that authors have switched to .f90.

Please consider changing the source file suffixes from .f95 to .f90.
The .f90 suffix means that the source code is free format, not that
the code conforms to the Fortran 90 standard. Code that uses the .f90
suffix can use features from any Fortran standard. All Fortran
compilers recognize .f90 as a suffix indicating free source form, but
some may not recognize a suffix such as .f95, .f03, .f08, or .f18.
Some users may have build tools that do not recognize suffixes other
than .f90. Most Fortran source code on GitHub that uses features from
a standard more recent than Fortran 90 still uses the .f90 suffix.

I think @certik has said that he would like to reclaim .f for free source form. Currently you need a compiler option to do this.

I have tweeted that

Since Fortran source files usually have the .f90 or .f suffix, you can Google, for example, “finite element” filetype:f90 and “finite element” filetype:f to find finite element codes.


When Fortran 90 arrived, it came with a new option for the source file format – the free-form Fortran source format. The current common convention is that .f signifies the old fixed format source (statements in col-7 or later, C in col-1 for comments, etc.), and .f90 is for free format Fortran source. Nothing is implied regarding the standard that the program conforms with. You can have a Fortran II program in a free form .f90 file, and you can have (with a few exceptions) a Fortran 2018 program in a fixed form .f file.

Here is an old Fortran II program in free form. Save it to a .f90 file and run it through your compiler.

   READ(5,501) IA,IB,IC
501 FORMAT(3I5)
   IF (IA) 701, 777, 701
701 IF (IB) 702, 777, 702
702 IF (IC) 703, 777, 703
777 STOP 1
703 S = (IA + IB + IC) / 2.0
   AREA = SQRT( S * (S - IA) * (S - IB) * (S - IC) )
801 FORMAT(4H A= ,I5,5H  B= ,I5,5H  C= ,I5,8H  AREA= ,F10.2, &

Some compilers (including Gfortran) will even take the following fixed form version, with semicolons separating multiple statements (created using Ian Harvey’s utility, FixedFormForEver).

  501 FORMAT(3I5);IF(IA)701,777,701
  701 IF(IB)702,777,702
  702 IF(IC)703,777,703
  777 STOP1
  703 S=(IA+IB+IC)/2.0;AREA=SQRT(S*(S-IA)*(S-IB)*(S-IC));WRITE(6,801)IA,
  801 FORMAT(4H A= ,I5,5H  B= ,I5,5H  C= ,I5,8H  AREA= ,F10.2,       13H

The standard is quite silent about the form a program is supposed to take. That is, the syntax and the layout (free versus fixed form) are defined, but they could as well be written in gothic characters on the back of a stack of envelopes for all it cares. The “processor” that runs the program could be a room full of students each working together in accordance to the statements. It does not have to be a “computer” as we now know them - the historical meaning of “computer” comes to mind :slight_smile:


Here is the issue to "reclaim .f" for modern Fortran: Reclaiming `.f` file extension for modern Fortran (free form) · Issue #363 · fortran-lang/fpm · GitHub, it’s obviously a little controversial, but it’s now over a year since I opened the issue and I still like the idea, I think we should do that. But until we do, currently the “standard” way is to use .f90 for modern Fortran. I recommend you do not use .f03 or .f95.


I wrote about this in Doctor Fortran in “Source Form Just Wants to be Free” - Doctor Fortran (

1 Like

Thank you all for your answers. It was a topic I avoided facing for years, knowing my file name convention needed to change. But when literally everything I use is modified according to such a convention, it’s not that easy (even my file manager is set so that foo.f08 is recognized as “Fortran 2008 source file”.) I reluctantly decided to go with *.f90, admitting it is the wisest decision… except for Fortran 95 code with TR15581 features, in which case it will be… foo.f95TR15581. Or should I let source lines being delivered to the “processor” by fairies in the night? (copied from @sblionel’s post in Doctor Fortran) :laughing:

I’m just kidding, *.f90 it is from now on. I said “reluctantly” adopting .f90 because Fortran 90 brought so many important new features that I consider free-form a rather secondary byproduct of the changes. In that sense, I always thought the file extension should describe the Fortran standard, not fixed- or free-form. I stopped using fixed-form as earlier as it was possible, and that was decades ago, so I assumed the extension has nothing to do with it anymore.

I am guessing I will keep seeing foo.f90 and immediately think that’s Fortran 90 code for quite some time, even if in reality it might be Fortran 2018. Momentum powered by decades is hard to beat. I doubt I am alone in that. So I think reclaiming .f file extension for modern Fortran is a great idea; it is not misleading, as it does not imply any Fortran standard by its own. However, until @certik’s reclaiming issue has more backers… *.f90 it is.

1 Like

I am having a hard time deciding whether or not Arjen’s metaphor with gothic characters triumphs the fairy one. :laughing:

Metaphors aside, for the past few weeks since I’ve begun using the new Intel Fortran compiler ifx, I’ve been thinking the extension .fx could be a nice way to settle this issue. The caveat is it may give the wrong impression that Fortran “belongs” to one particular vendor.

My personal preference would be either .for or .ftn (I think Cray might currently use .ftn). Also anything with a .for or .ftn extension would be by default

  1. free format only
  2. imply implicit none by default (no need for any additional compiler switches etc).
  3. be able to contain preprocessing directives (hopefully for a native Fortran preprocessor) without making the extension upper case (which would avoid issues on file systems that dont differentiate between a.f90 and a.F90). Preprocessing would be signaled by the existence of a -D clause on the compiler statement

Since the vast majority of the people on this forum now refer to the current version of Fortran as “Modern Fortran” and no longer use whatever date label is attached to the current standard, its time to do the same with the file extension.

You may have seen my extension table previously (Support additional file extensions · Issue #250 · fortran-lang/fpm · GitHub):

Compiler Fixed-form Fixed-form with preprocessor Free-form Free form with preprocessor
gfortran .f, .for, .ftn .fpp, .F, .FOR, .FPP, .FTN .f90, .f95, .f03, .f08 .F90, .F95, .F03, .F08
ifort .f, .for, .ftn, .i .fpp, .FPP, .F, .FOR, .FTN .f90, .i90 .F90
nvfortran .f .for .ftn .F .FOR .FTN .fpp .FPP .f90 .f95 .f03 .F90 .F95 .F03
nagfor .f, .for, .ftn .ff, .F .f90, .f95 .ff90, .ff95, .F90, .F95
Cray .f, .for .F, .FOR .f90, .f95, .f03, .f08, .f18, .ftn .F90, .F95, .F03, .F08, .F18, .FTN
IBM .f, .f77 .F, .F77 .f90, .f95, .f03, .f08 .F90, .F95, .F03, .F08
g95 .f, .for .F, .FOR .f90, .f95, .f03 .F90, .F95, .F03

.ftn is the most controversial one, since Cray interprets it as free-form, while NAG, gfortran, ifort, and NVIDIA interpret it as fixed form.


I recently changed my suffix from .f2x to .f23. :slight_smile:

1 Like

amazing how memory betrays you as you grow older. I had forgotten that .for has been around for a long time and didn’t realize its still supported. I think it was the file extension on DEC VAX systems but don’t quote me on that. Whatever the final form might take, I still think its time to move away from the .f90, .f , .F90 etc extensions and move to one that doesn’t change with each new standard and doesn’t use a different extension for files containing preprocessor directives

I’m glad the young Fortran is back, I’m sure .f23 beats the old .f90 in every category.

This just made me realize: Fortran 90 is as far from FORTRAN I (1957) as it is from Fortran 2023! :open_mouth:

1 Like

I’m pretty sure that, at least in the *NIX world (and definitely in GNU/Linux) .f was the most common extension for FORTRAN 77… erm, sorry, fixed-form, I mean. Still, that’s an old story, and I don’t think reclaiming .f for modern Fortran would confuse anyone.

1 Like

It would confuse me. I still have some fixed-form f77 subroutines ending .f and sometimes use them in free-form .f90 programs. Sometimes I translate one from .f to .f90 ; it is then essential that both versions be available while checking whether the translation is correct.

Rule no 1 for my programing - what does Intel let me do.
Rule no 2 - decide this site is just a large water cooler site for extreme Fortran users, you meet these sort of people on the higher ski slopes arguing whether a snow board or skis are better.
Question No 1 - where is the coffee urn, has someone got a camera on it – (if you fail to understand this joke, you are not old enough, do not worry one day you will be.)

1 Like

@macneacail I googled your joke and it’s good one :rofl:

Should we extend the extension from .f08 to .f2018? The language already lasts 70 years, what if it lasts for more than 200 years and still being used? By then we will have confusing file extensions, does f90 mean f1990 or f2090? If larger projects could clearly identify the standard used by each source file, for example, if you open a src folder and see something like the following

- driver.f1990
- utility.f2003
- math.f1977
- parallel.f2008
- template.f2023

it will be helpful for developers/compilers/build tools to identify which standard to use when compiling the project. If a language gets used for too long, more features will become obsolete and new features will be added, it will become the Ship of Theseus. Fortunately and unfortunately Fortran is the first language that faces this problem. I’ve heard the sentence “This is not your grandfather’s Fortran.”, but what the sentence implies or what it will eventually become is “This is not THE Fortran any more, although it is still called Fortran.” By then, anything that could distinguish “this Fortran” from “that Fortran” will become important.


Fortran is the first computer language that faces that problem but not the first language that does. If thou canst read this thou knowest one.

When I found that school mathematics has far fewer proofs of theorems than it used to, I have sometimes referred to it as another subject with the same name. (When I was teaching a first-year university mathematics class a few decades ago I was saddened that all the students knew what Pythagoras’s theorem said but none of then knew why it was true. So I told them Euclid’s and what Wikipedia calls the rearrangement proof.)


NO! It is wrong to conflate the extension with the version of the standard you think you are writing for. I have advocated for .ffr meaning Fortran free-form, but practically speaking, .f90 is universally used and supported.

I’ll also observe that few programmers really know which standard they are using, and once you use an extension the idea goes out the window.