Dateibenennung: Regeln und Vorlagen, die wirklich funktionieren

Du willst einem Kunden eine Datei schicken, und der Ordner liefert dir final_v2, final_FINAL und final-neu. Du öffnest die eine, dann die andere, und schreibst schließlich einer Kollegin, welche davon eigentlich rausgegangen ist. Die Arbeit ist erledigt. Das Wiederfinden ist das Problem.

Genau dafür sind gute Regeln zur Dateibenennung da. Ein guter Name verrät einem Fremden, was eine Datei ist, wohin sie gehört und ob sie aktuell ist, ohne dass jemand sie öffnen muss. Außerdem muss er den Weg auf einen anderen Rechner, ein gemeinsames Laufwerk oder ein anderes Betriebssystem überstehen.

Die Benennungsvorlage, die jedes Team übernehmen kann ​

Fang mit diesem Namen an:

NORTH-2026-03-14_brand-logo-concept_v03_final.psd

Lies ihn von links nach rechts. NORTH ist das Projekt. 2026-03-14 ist das Datum. brand-logo-concept beschreibt den Inhalt. v03 ist die Version. final ist der Status. .psd ist die Endung, die das Programm angehängt hat.

Die Reihenfolge ist wichtig. Setz das stabilste Element an den Anfang, meist den Projektcode, damit ein sortierter Ordner die Arbeit erst nach Projekt und dann nach Zeit gruppiert. Steht die Beschreibung vorn, verteilen sich Dateien aus verschiedenen Projekten quer durch die Liste, und die Suche macht die Arbeit, die eigentlich dein Name hätte erledigen sollen.

Die sechs Elemente in der richtigen Reihenfolge ​

Ein paar Punkte bringen Leute regelmäßig ins Stolpern. Deine Beschreibung sollte sagen, was drinsteckt, nicht wie fertig es ist. "brand-logo-concept" funktioniert. "neue-version" nicht, denn "neu" stimmt morgen schon nicht mehr. Diese Bedeutung trägt der Status, aber nur, wenn du ihn auf eine kurze Liste beschränkst. Sobald jemand "final-ish" oder "freigegeben-vielleicht" ergänzt, ist das Statuselement nicht mehr durchsuchbar.

Die Version ist wieder eine eigene Sache. Eine Datei kann v03 und trotzdem ein Entwurf sein, oder v07 und final. Halte diese Ideen in getrennten Feldern, dann brauchst du nie Namen wie final2 oder final-wirklich-final.

Wenn du auch Produkte oder Features benennst, ist Sprellos Leitfaden zur Produktbenennung eine nützliche Ergänzung, weil er dieselbe Disziplin von der Namensseite her angeht: Bezeichnungen kurz, konsistent und für Außenstehende leicht lesbar halten.

Der Fremden-Test ​

Stell dir vor dem Speichern drei Fragen.

• Was ist das? Die Beschreibung sollte das beantworten, ohne dass man die Datei öffnet.
• Zu welchem Projekt gehört es? Der Code sollte auf einen Blick erkennbar sein.
• Ist das die aktuelle Version? Version und Status sollten das klären.

Du brauchst nicht jedes Mal alle sechs Elemente. Ein privates Foto braucht vielleicht nur Datum und Beschreibung. Was du aber brauchst, ist jedes Mal dieselbe Reihenfolge, damit fehlende Elemente nicht alles andere verschieben.

Warum Namenskonventionen im Alltag scheitern ​

Viele Gruppen geben sich durchaus Mühe. Es fehlt ihnen eine Vereinbarung, die eine stressige Woche überlebt.

Stell dir einen Aktenschrank mit unbeschrifteten Schubladen vor. Jedes Papier steckt irgendwo drin, aber um eines zu finden, musst du jeden Umschlag aufmachen. Ein gemeinsamer Ordner voller Dateien namens "Präsentation", "Präsentation neu" und "Präsentation März" funktioniert genauso. Die Dateien sind da. Das System zum Wiederfinden fehlt.

Zwei Fehlerbilder verursachen das meiste Chaos.

Namen driften auseinander. Einer schreibt Daten als 14-03-2026, ein anderer als 2026-03-14, ein dritter lässt sie unter Termindruck ganz weg. Nach einem Monat nutzt dasselbe Projekt drei Datumsformate und zwei Versionsschemata, und Sortieren ergibt keinen Sinn mehr.

Namen ergeben nur für ihre Urheber Sinn. "Entwurf für Sarah" ist am Tag des Speicherns völlig klar. Sechs Monate später, nachdem Sarah das Team gewechselt hat, sagt es niemandem mehr etwas. Auch dein zukünftiges Ich ist hier ein Fremder. Wenn du eine Datei ein Jahr später nicht mehr einordnen kannst, hat der Name versagt, obwohl du ihn selbst geschrieben hast.

Das ist kein seltenes Problem. In einer branchenübergreifenden Studie von 2026, veröffentlicht von Daniel Coward auf LinkedIn, die mehr als 200 Unternehmen und rund 10.000 Dateien umfasste, wiesen 73 % der Dateinamen Probleme auf, etwa uneinheitliche Datumsformate, unklare Versionierung oder fehlenden Kontext.

Was eine funktionierende Konvention tatsächlich löst ​

• Auffindbarkeit: Suchst du nach einem Projektcode, tauchen alle zugehörigen Dateien auf, auch ordnerübergreifend.
• Sortierung: Eine Listenansicht liest sich nach Projekt und Zeit geordnet, ohne dass du manuell umsortieren musst.
• Übergaben: Designer, Entwickler, Betreuer und Kunden erkennen die richtige Datei, ohne nachzufragen.

Benennung ist Teil eines größeren Ordnungssystems, und Teams mit großen Asset-Bibliotheken finden hilfreiche Gedanken im Beitrag über den Aufbau einer skalierbaren Taxonomie für digitale Assets, der zeigt, wie Kategorien und Bezeichnungen halten, wenn Sammlungen wachsen.

Eine Konvention ist nur so gut wie die Bereitschaft des Teams, sie zu nutzen. Eine perfekte Vorlage in einem Dokument, das niemand liest, ändert nichts, deshalb muss der Aufbauprozess diese Zustimmung gleich mit erzeugen.

So baust du deine Konvention in sechs Schritten ​

Hier der ganze Ablauf auf einer Seite, bevor wir ihn durchgehen.

1. Benenne den Zweck. Schreib die drei Fragen auf, die jede Datei schnell beantworten muss, meist: Was ist es, zu welchem Projekt gehört es, und welche Version ist es? Regeln ohne Zweck fliegen beim ersten Termindruck raus, weil niemand erklären kann, wozu sie gut sind.

2. Wähle vier bis sechs Elemente und lege ihre Reihenfolge fest. Such aus Projektcode, Datum, Beschreibung, Version, Status und Rolle aus. Der Fehler, den du vermeiden solltest: Elemente hinzuzufügen, die niemand ausfüllt. Wenn dein Team nicht bei jeder Datei einen Ort oder einen Kundenkontakt vermerkt, lass ihn weg, denn ein Element, das halb leer bleibt, stört das Muster für alle.

3. Lege Trennzeichen und Schreibweise fest. Nimm Bindestriche zwischen Wörtern innerhalb eines Elements und Unterstriche zwischen Elementgruppen, durchgehend Kleinbuchstaben außer bei Projektcodes, und keine Leerzeichen. Leerzeichen bringen Skripte auf der Kommandozeile und manche Weblinks durcheinander, und solche Namen lassen sich schlechter per Doppelklick markieren. Wähl ein Schema und lass nicht jeden Bindestriche und Unterstriche nach Gutdünken mischen.

4. Leg Datums- und Versionsregeln fest. Daten stehen als JJJJ-MM-TT, Versionen beginnen bei v01, und du definierst einmal, ob das Datum Erstellung oder Lieferung meint. Diese eine Definition erspart dir einen stillen Streit, der sonst jahrelang schwelt, weil die eine Hälfte des Teams nach Erstellung und die andere nach Lieferung datiert.

Sieh dir die Schritte in der Praxis in einem kurzen Video an, bevor du deinen eigenen Leitfaden entwirfst.

5. Schreib einen einseitigen Leitfaden. Nimm fünf gute und fünf schlechte Beispiele auf, dazu eine Regel für Ausnahmen wie Altdateien, die du nicht umbenennst. Halt ihn auf einer Seite. Ein zwölfseitiger Standard signalisiert, dass Benennung Bürokratie ist, und Bürokratie wird umgangen. Pinn die Seite dort an, wo Dateien gespeichert werden, nicht in einen Richtlinien-Ordner, den niemand öffnet.

6. Pilotier das Ganze zwei Wochen an einem aktiven Projekt. Überarbeite danach die zwei oder drei Regeln, die am häufigsten gebrochen wurden. Ohne Pilot entstehen Regeln, die niemand nutzt, weil du zu spät merkst, dass sich ein Element beim Speichern nur schwer liefern lässt.

Wenn eine Regel im Pilot immer wieder gebrochen wird, ist das eine Information über die Regel, keine Faulheit des Teams.

Woran du erkennst, dass es funktioniert ​

Sortierte Listen lesen sich wie eine Zeitleiste. Jeder im Team findet die neueste finale Datei in unter zehn Sekunden, und Neue können ihre Dateien am ersten Tag allein mit dieser einen Seite richtig benennen.

Datums- und Versionsformate, die richtig sortieren ​

Öffne einen Ordner mit 3-4-26, 2-11-26 und 10-3-26. In der Listenansicht sortieren sie nach dem ersten Zeichen, also steht 10-3-26 vor 2-11-26, und die Zeitleiste ist durcheinander. Nimm jetzt Versionen wie v1, v10 und v2 dazu, und der Computer setzt v10 vor v2, weil Textsortierung Zeichen für Zeichen liest und "1" vor "2" kommt.

Beide Probleme wirken wie Nachlässigkeit. Es sind Formatprobleme, und sie haben mechanische Lösungen.

Warum das Jahr zuerst kommt ​

JJJJ-MM-TT sortiert in jedem Dateimanager chronologisch, weil die größte Einheit vorn steht und jede Einheit eine feste Breite hat. TT-MM-JJJJ sortiert nach Tag, sodass sich der Erste jedes Monats zusammenballt. Und 3-4-26 hat noch ein zweites Problem: Es ist je nach Wohnort des Lesers zwischen 3. April und 4. März mehrdeutig, und ein zweistelliges Jahr überlässt das Jahrhundert dem Raten.

Microsofts eigene Hinweise kommen für plattformübergreifende Arbeit zum selben Schluss. Die Microsoft-Dokumentation zur Dateibenennung unterstützt Formate mit vorangestelltem Datum wie JJJJ-MM-TT, um die lexikalische Sortierung zu verbessern, zusammen mit stabilen Projekt- und Versionskürzeln, die bei der Stapelverarbeitung Mehrdeutigkeiten verringern.

Datum und Version getrennt halten ​

Das Datum hält fest, wann eine Datei erstellt oder geliefert wurde. Die Version hält fest, welche Iteration der Arbeit es ist. Das sind verschiedene Fakten: Zwei Dateien vom selben Tag können sich in der Version unterscheiden, und eine Version kann an einem späteren Datum erneut geliefert werden. Wirfst du beides zusammen, verlierst du eine der beiden Angaben.

Auffüllen mit Nullen sorgt dafür, dass Versionen richtig sortieren. Schreib jede Zahl zweistellig, von v01 bis v99, damit v02 vor v10 steht. Wenn ein Projekt absehbar über neunundneunzig Iterationen hinausgeht, fang gleich mit v001 an, statt mittendrin umzustellen.

Stabile Kürzel helfen auch Skripten. Ein fester Projektcode und eine kleine Menge Statuswörter lassen ein Stapel-Tool Dateien zuverlässig zuordnen. Deshalb lohnt sich ein Blick in den Leitfaden zum Stapel-Umbenennen von Dateien auf dem Mac, sobald dein Muster steht. Datenintensive Teams erkennen dieselbe Disziplin in Ansätzen, um Versionen von Robotikdaten zu verwalten, wo ein Versionskürzel über viele automatisierte Läufe hinweg eindeutig bleiben muss.

Für Teams über Zeitzonen hinweg gilt: Datier die Lieferung in der Zeitzone des Teams und schreib diese Regel in den Leitfaden, damit eine Datei, die kurz vor Mitternacht rausgeht, ein einheitliches Datum bekommt.

Zum Schluss noch eine Regel, die Versionsinflation verhindert. Erhöhe die Version bei jedem Speichern, das an jemand anderen geht, nicht bei jedem Speichern, das du selbst machst. Deine lokalen Arbeitsstände sind deine Sache. Die Versionsnummer ist ein Kommunikationsmittel für andere.

Zeichen, Akzente und Längenlimits, die Übertragungen sprengen ​

Hier eine verbreitete Annahme, die man hinterfragen sollte: Wenn dein Mac einen Namen akzeptiert, ist der Name in Ordnung.

Stimmt nicht. Das strengste System in deinem Arbeitsablauf setzt die Grenze, nicht der Mac, auf dem die Datei entstanden ist. Ein Name, der zu Hause völlig legal ist, kann sich nicht auf ein Windows-Volume kopieren lassen, von einem Sync-Dienst umbenannt werden oder in einem tiefen Ordnerbaum unerreichbar werden. Die meisten Tipps zur Benennung hören bei der Lesbarkeit auf. Das Übertragungsrisiko ist der Teil, der Dateien verliert.

Das Akzent-Problem in einfachen Worten ​

Ein Buchstabe mit Akzent kann auf zwei Arten gespeichert werden. Entweder als ein einziges vorkomponiertes Zeichen oder als Grundbuchstabe plus separates kombinierendes Zeichen. Auf dem Bildschirm sehen beide identisch aus.

Wie der Leitfaden zu Unicode in Dateinamen erklärt, liefert macOS häufig dekomponierte, NFD-artige Namen, während Linux-Umgebungen oft NFC verwenden oder die Normalisierung unverändert lassen. Dieser Unterschied kann zu doppelt wirkenden Dateinamen, fehlgeschlagenen Vergleichen, kaputten Skripten oder Synchronisierungskonflikten führen, obwohl Nutzer identischen Text sehen.

Dazu kommt ein zweiter Haken. Die Dateinamenlänge wird in Bytes statt in sichtbaren Zeichen gemessen, und das Dekomponieren akzentuierter Zeichen erhöht die Byteanzahl. Ein Name, der scheinbar unter dem Limit liegt, kann nach Übertragung oder Verarbeitung das Limit von 255 Bytes pro Komponente überschreiten. Deshalb ist das Zählen von Zeichen im Finder eine trügerische Beruhigung.

Der ehrliche Kompromiss bei reinen ASCII-Namen ​

Alles auf reines ASCII zu beschränken verbessert zwar die Interoperabilität. Es opfert aber Barrierefreiheit, Durchsuchbarkeit und kulturelle Korrektheit, weil es im Spanischen, Deutschen, Japanischen und in vielen anderen Sprachen falsche Schreibweisen erzwingt. Einem Kollegen zu sagen, er solle seinen eigenen Namen falsch schreiben, damit ein Skript läuft, ist keine Richtlinie, sondern Kapitulation.

Nimm stattdessen einen mehrschichtigen Ansatz.

• Behalte den muttersprachlichen Anzeigenamen. Personen- und Ortsnamen bleiben dort korrekt geschrieben, wo Menschen sie lesen.
• Normalisiere vor dem Speichern auf NFC, wo deine Tools das erlauben, damit alle Systeme dieselbe Bytefolge vergleichen.
• Führe einen ASCII-Slug als maschinelle Kennung. Skripte und Sync-Tools gleichen über den Slug ab, während Menschen den Anzeigenamen lesen.
• Teste den echten Übertragungsweg. Schick Beispieldateien einmal hin und zurück durch das NAS, das Cloud-Laufwerk oder das Git-Repository, das dein Team tatsächlich nutzt.

Unicode ist in Ordnung. Normalisiere es konsequent, prüfe die Bytelänge und stell sicher, dass es die Reise übersteht.

Rollenbasierte Vorlagen für Kreative, Entwickler, Studierende und Forschende ​

Die gleichen Elemente funktionieren für jede Rolle. Was sich ändert, ist, welches Element am meisten Gewicht trägt, denn jede Rolle leidet unter einer anderen Art von Verwechslung.

Kreative stellen den Kunden- oder Projektcode und den Asset-Typ voran. Eine Kampagne kann Hunderte Iterationen desselben Banners enthalten, deshalb muss die Version eindeutig sein, und der Asset-Typ muss ein Homepage-Banner auf einen Blick von einem Social-Zuschnitt unterscheiden. Ohne das Asset-Element öffnest du Dateien, nur um die Abmessungen zu prüfen.

Entwickler arbeiten in Repositories, die ohnehin Kleinbuchstaben und keine Leerzeichen vorschreiben, also kämpf nicht dagegen an. Nutz den Namen stattdessen für Komponente und Dokumenttyp. shop-api_auth-flow_spec_v02.md sagt einem Reviewer genau, welchen Teil des Systems es beschreibt, und das ist wichtiger als ein Datum, das die Commit-Historie ohnehin festhält.

Studierende sollten zuerst dem folgen, was die Lehrperson vorgibt. Wo nichts vorgegeben ist, sollte der Name Kurscode, Aufgabe und Abgabestatus tragen, damit jemand, der einen ganzen Stapel Abgaben bearbeitet, deine Arbeit in Sekunden findet. Ein Nachname hilft, wenn Abgaben in einem gemeinsamen Postfach landen.

Forschende haben die höchsten Einsätze. Benenn Rohdaten und bereinigte Daten unterschiedlich, setz Rohdateien auf schreibgeschützt und verankere alles an einer Studienkennung und einem Datum. Wenn bereinigte Daten die Rohdaten unter demselben Namen überschreiben, lässt sich die Studie nicht reproduzieren.

Ausnahmen behandeln, ohne das System zu sprengen ​

Manchmal erzwingt eine Plattform eigene Regeln. Ein Abgabeportal benennt Uploads womöglich um, oder ein Tool verlangt ein bestimmtes Muster. Folge der Plattform und halte den menschenlesbaren Namen in einer README oder einem Projektindex fest, damit die Verbindung nicht verloren geht.

Dasselbe gilt über Sprachen hinweg. Der Anzeigename kann muttersprachlich bleiben, während die maschinelle Kennung ASCII bleibt. So sind Menschen und Tools zufrieden.

Benennung funktioniert am besten, wenn die Ordnerstruktur einen Teil der Last trägt. Kombinier diese Vorlagen also mit einer sinnvollen Projektordner-Struktur, statt jede Information in den Dateinamen zu pressen. Wenn du Kunde, Kampagne, Region und Kanal in einen Namen stopfst, gehört ein Teil davon in Ordner.

Eine Konvention einführen und die Prüfungen automatisieren ​

Viele Teams treffen diese Vereinbarung gar nicht erst. In Smallpdfs Umfrage von 2026 unter 1.000 berufstätigen US-Amerikanern gaben 55 % an, ihr Team habe keine gemeinsame oder standardisierte Dateibenennungs-Konvention.

Deshalb kommt die Einführung vor der Durchsetzung. Veröffentliche den einseitigen Leitfaden, hol dir das Okay der Leute, die Dateien erstellen, und wende ihn auf ein aktives Projekt an, bevor du ihn überall ausrollst. Eine Konvention, die per E-Mail an die ganze Organisation verkündet wird, ist meist bis Freitag tot.

Drei Automatisierungsstufen ​

Stufe eins prüft Dateien beim Eintreffen. Richte Umbenennungsregeln für eingehende Ordner ein, etwa eine Automator-Ordneraktion auf dem Mac oder ein Tool, das Ordner überwacht und neue Downloads markiert oder korrigiert. Wenn du Optionen abwägst, bietet dieser Überblick über Automatisierungs-Apps für den Mac Tools, die Ordner beobachten und auf neue Dateien reagieren können.

Stufe zwei prüft, was schon da ist. Ein kurzes Skript unter Windows oder Linux kann jede Datei auflisten, die das Muster verletzt, geprüft gegen dieselbe Elementreihenfolge wie in deinem Leitfaden. Lass es über einen Projektordner laufen, und du siehst die Abweichungen sofort, auch wer eine Auffrischung braucht.

Stufe drei verfolgt den Trend. Führ vierteljährlich eine Prüfung durch, die regelwidrige Namen zählt, und trag die Zahl über die Zeit auf. Eine sinkende Zahl zeigt dem Team, dass sich die Gewohnheit festigt. Eine steigende Zahl heißt, dass eine Regel zu schwer einzuhalten ist und überarbeitet werden muss, nicht dass du lauter durchsetzen solltest.

Was du mit bestehenden Dateien tun solltest ​

Benenn ein Archiv nicht blind um. Führ eine Zuordnungstabelle von alten zu neuen Namen, damit sich Links in Dokumenten, Tickets und E-Mails reparieren lassen, wenn sie brechen. Benenn zuerst aktive Projekte um und lass abgeschlossene Archive in Ruhe, solange niemand mehr darin sucht.

Tu diese Woche eine Sache. Nimm das nächste Projekt, schreib seine Vorlage auf eine Seite, benenn einen Ordner entsprechend um und richte eine Prüfung ein, die bei jeder neuen Datei läuft. Dieses kleine, funktionierende Beispiel überzeugt Leute weit besser als eine Rundmail mit Richtlinie.

Sobald deine Namen konsistent sind, kannst du die Ordner selbst leichter erkennbar machen. Tintd liest den Namen eines Ordners und wählt ein passendes Symbol samt Farbe, und der Folder Watcher gestaltet neue Ordner an den von dir gewählten Orten automatisch, sodass ein gut benanntes Projekt auch im Finder sofort wiederzuerkennen ist. Wirf einen Blick auf Tintd und sieh, wie visuelle Ordnung auf dem Benennungssystem aufsetzen kann, das du gerade aufgebaut hast.