Introduction

Getting a file name without its extension sounds trivial until edge cases show up. Hidden files, multiple extensions such as archive.tar.gz, and full paths all change what "without extension" is supposed to mean, so the best solution is usually a path-aware library rather than raw string slicing.

What Needs to Be Removed

A typical filename has two logical parts:

• the base name
• the extension after the last dot

For report.pdf, the base name is report. For archive.tar.gz, many libraries treat only .gz as the extension, leaving archive.tar as the stem. Whether that is correct depends on your use case.

Python Examples

os.path.splitext removes only the last extension:

1import os
2
3print(os.path.splitext("report.pdf")[0])
4print(os.path.splitext("archive.tar.gz")[0])

Output:

report
archive.tar

pathlib gives the same basic behavior with a nicer API:

1from pathlib import Path
2
3print(Path("report.pdf").stem)
4print(Path("archive.tar.gz").stem)

If you need to strip every suffix:

1from pathlib import Path
2
3path = Path("archive.tar.gz")
4name = path.name
5for suffix in path.suffixes:
6    name = name.removesuffix(suffix)
7
8print(name)

JavaScript Example

If you only need the last extension removed:

1function removeLastExtension(filename) {
2  const index = filename.lastIndexOf(".");
3  return index > 0 ? filename.slice(0, index) : filename;
4}
5
6console.log(removeLastExtension("report.pdf"));
7console.log(removeLastExtension("archive.tar.gz"));
8console.log(removeLastExtension(".env"));

Using index > 0 avoids turning .env into an empty string. That is an important edge case many simple snippets miss.

Bash Example

Shell parameter expansion is concise:

file="report.csv"
name="${file%.*}"
echo "$name"

This removes the shortest suffix matching .*. It is useful in scripts, but it is still string-based, so it does not magically understand filesystem semantics.

Paths Versus Names

Another common source of bugs is mixing the full path with the filename. If the input is /tmp/report.pdf, you may want:

• just the stem: report
• the path without extension: /tmp/report

Libraries often let you choose clearly, which is safer than manually splitting on / and . yourself.

That difference matters in batch-processing scripts. A filename-only operation is fine for display logic, but if you intend to write output next to the source file, dropping the directory portion accidentally can put the new file in the wrong place.

That is one reason path objects tend to age better than ad hoc string code.

They also make later refactoring easier, because once you need parent directories, suffix lists, or normalized joins, the path object is already carrying the right semantics instead of forcing you to rebuild them from string fragments.

Hidden Files and Multi-Part Extensions

Files such as .gitignore and .env are not ordinary "name plus extension" cases. Many tools treat the leading dot as part of the name, not as an extension separator. Multi-part extensions create a second ambiguity: does .tar.gz count as one logical extension or two? The correct answer depends on the application, so make the rule explicit in code.

Common Pitfalls

• Removing text after the first dot instead of the last dot.
• Breaking hidden files such as .env.
• Ignoring full paths and operating on directory names by accident.
• Assuming archive.tar.gz should always become archive.
• Using raw string operations when a path library already solves the problem.

Summary

• Use a path-aware library when possible.
• Most standard helpers remove only the last extension.
• Hidden files and multi-part extensions require explicit policy decisions.
• Keep path handling separate from filename handling.
• Small edge cases make this problem more subtle than it first appears.