Design - static utility classes or interface?

Hello stackoverflowers,

I want to export processed datas in several different ways : JSON file, XML file and SPList (add in a sharepoint list), maybe others later, who knows. I don't choose the export strategy at runtime, i just want to have the three ready in case 'someone' change its mind...

I have a class corresponding to each way (no class field, only two methods for import and export, is that what is called "stateless classes" ?).

I'm a bit confused about what kind of implementation would be the best.

I could make three static classes, as these are 'utility classes' i believe, and call them easily without bothering with instanciation, those methods would be kind of "fire'n'forget". If new export ways are needed, i'll have a large number of isolated classes.

On the other hand i could make an interface with import and export method, and have my classes implement the interface. But it makes me create instances for only one call, and i don't really need a factory (i don't choose at runtime for the moment) and don't find the interface strongly justified (no need for polymorphism ?) and if a new method is added, i can just implement interface again, if there is no need for new parameters.

Which one would you use, static utility classes or interfaces ? or something else maybe ?