No module named 'keras.saving.hdf5_format'
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
The error No module named 'keras.saving.hdf5_format' usually appears when code imports a private Keras module path that is no longer part of the public API. The fix is almost never to hunt for that internal file. The right fix is to use Keras' supported save and load functions from the public API.
Why This Import Breaks
Older blog posts and copied snippets sometimes import internals such as keras.saving.hdf5_format directly. That is fragile because internal module layouts are free to change between Keras releases. Public functions such as keras.models.load_model and model.save are the stable entry points you are supposed to call.
This problem is more common when a project mixes:
- standalone
keras - '
tensorflow.keras' - code written for one version and run under another
Once those pieces drift apart, internal imports are often the first thing to fail.
Use the Public Save and Load API
If your real goal is to save or load a model, do that through Keras itself instead of importing a helper from an internal module.
This uses the supported .keras model format and avoids any dependency on internal HDF5 helpers.
If you still need the legacy HDF5 format for interoperability with older tooling, use the same public API and choose an .h5 filename:
The important point is that the import stays public even when the storage format is legacy.
Keep Your Keras Stack Consistent
The other half of this error is environment consistency. Pick one Keras stack and use it throughout the project. If your codebase imports from keras, keep that style consistent. If it imports from tensorflow.keras, stay there consistently instead of mixing both styles in the same module tree.
A quick check helps when you are debugging:
If the environment contains unexpected versions or conflicting packages, reinstalling the intended stack in a clean virtual environment is often faster than trying to patch around it.
Do Not Depend on Private Modules
This is the broader lesson behind the specific error. If an import path looks like an implementation detail, treat it as one. Reaching into internal modules may work for a while, but it becomes technical debt because future versions are free to reorganize those files.
For Keras model IO, the public API already gives you what you need:
- '
model.save(...)' - '
keras.models.load_model(...)' - supported formats such as
.kerasand legacy.h5
That is the stable layer to build on.
Common Pitfalls
The most common mistake is copying an import from an old answer that reached into keras.saving.hdf5_format directly. That code was relying on internals, not on the supported API.
Another issue is mixing keras and tensorflow.keras imports in the same project. Even when the code imports successfully, that inconsistency can create confusing runtime behavior and dependency mismatches.
People also sometimes assume HDF5 support itself is gone. The error does not mean HDF5 is impossible. It means the internal module path is not the right way to access model saving logic.
Summary
- '
keras.saving.hdf5_formatis an internal module path and should not be imported directly.' - Use public APIs such as
model.save(...)andkeras.models.load_model(...)instead. - Prefer the modern
.kerasformat unless you specifically need legacy.h5. - Keep your Keras and TensorFlow package choices consistent across the environment.
- When in doubt, fix the import strategy rather than searching for a missing internal file.

