|
||||||||
|
Configuration: Installation / Integration:
|
Application icons are icons in Windows ICO format. They can be used in
Windows shortcuts and/or as file association icons. The KeePass executable
contains various application icons which can be used for these purposes. Additional application icons are available from the " Ext/Icons_* "
directories of the KeePass source code package.
Most of them, shown at right, are slight variations of the main KeePass icon.Even more, contributed icons (by users) can be found on the plugins page. If you have multiple KeePass databases, you can use differently colored KeePass application icons in order to distinguish them. These icons are not included in the binary distribution because this would make the application file too large. |
![]() |
Client icons are the icons used for password entries and groups within KeePass.
Each entry can be assigned its own icon. KeePass 1.x Only
These icons are built-in. You cannot add/import your own icons.
KeePass 2.x Only
You can import your own icons into KeePass databases. For this, click the 'Add...'
button in the icon picker dialog.Supported formats are BMP, EMF, GIF, ICO, JPEG, PNG, TIFF and WMF. |
![]() |
On Polish systems, the default auto-type hot key Ctrl+Alt+A conflicts with a system command and is frequently used in typing. Therefore, auto-type is often executed accidentally.
The global auto-type hot key can be changed to a different key combination in the KeePass options (see Auto-Type for details).
Symptoms: When trying to print a password list in KeePass 1.x, nothing happens after clicking OK in the 'Print Options' dialog.
Cause: KeePass 1.x uses the application associated with .html
files to print the password list. If this application doesn't support the
"print" shell verb (like Mozilla Firefox), nothing happens.
Resolution: Associate .html
files with a different
application that supports the "print" shell verb (like Internet Explorer).
Alternative Resolution / Workaround: Click 'File' → 'Print Preview' in KeePass 1.x and manually print the document in the application that just opened the file.
KeePass has an option to automatically check for updates on each program start. In order to check for updates, KeePass downloads a small version information file and compares the available version with the installed version. No personal information is sent to the KeePass web server.
Automatic update checks are performed unintrusively in the background. A notification is only displayed when an update is available. Updates are not downloaded or installed automatically.
When starting KeePass for the first time, it asks whether to enable automatic update checks (recommended). They can be enabled/disabled at any time using the option in 'Tools' → 'Options' → tab 'Advanced'.
Yes. KeePass supports all system themes, including dark ones.
Example (Windows 11, 'Dusk' theme):
Option 'Choose your (default app) mode' → 'Dark'.
Windows 11 has an option 'Choose your mode' (on Windows 10, it is called
'Choose your default app mode'), which can be set to 'Dark'.
Note that this option applies to UWP apps only, not to regular Windows applications.
Windows allows the UWP option to contradict the system theme
(e.g. a light system theme may be active even when the UWP option is set to 'Dark').
KeePass is a regular Windows application, not a UWP app,
thus it follows the system theme, not the UWP option.
This is the expected behavior; KeePass does not have anything to do
with UWP options.
Custom appearance.
If you want to change KeePass' appearance independent of the active
system theme, you might be interested in the
KeeTheme plugin.
KeePass uses the default graphical user interface (GUI) font that has been specified in the operating system settings. So, if you want to change the font (especially the size of the font) that KeePass uses, change it globally.
In addition to supporting these system settings, KeePass allows to customize the fonts that are used in lists and for passwords (in the options dialog; these settings affect KeePass only, no other applications).
If you only want to change the font of the KeePass GUI (which typically is not a good idea): the KeeUIExt plugin provides an option for this. However, it is recommended to use the above settings instead.
Is the Auto-Type feature resistant to keyloggers?
No. Auto-Type only checks whether the title of the currently active top level window matches.
Browsers like Mozilla Firefox completely draw the window (all controls) themselves, without using standard Windows controls. Consequently it is technically impossible for KeePass to check whether a URL matches (methods like creating a screenshot and using optical character recognition are not reliable and secure). Also, it's impossible to check which child control currently has the focus. These problems can only be avoided by using browser integration plugins, i.e. not using auto-type at all.
The user must make sure that the focus is placed in the correct control before starting auto-type.
KeePass has various options to lock its workspace automatically (after some time of inactivity, when the computer gets locked or the user is switched, when the computer gets suspended, etc.). However, the workspace is not locked automatically while a sub-dialog (like the 'Edit Entry' dialog) is open.
To understand why this behavior makes sense, it is first important to know what happens when the workspace gets locked. When locking, KeePass completely closes the database and only remembers several view parameters, like the last selected group, the top visible entry, selected entries, etc. From a security point of view, this achieves the best security possible: breaking a locked workspace is equal to breaking the database itself.
Now back to the original question. Let's assume a sub-dialog is open and one of the events occurs that should automatically lock the workspace. What should KeePass do now? In this situation, KeePass cannot ask the user what to do, and must make an automatic decision. There are several possibilities:
Obviously, none of these alternatives is satisfactory. Therefore, KeePass implements the following simple and easy to understand behavior:
KeePass doesn't lock while a sub-dialog is open.
This simple concept avoids the problems above. The user is responsible for the state of the program.
Note that opening a sub-dialog is typically only required for editing something; it is not required for using entries, as the main window provides various methods for this.
Locking when Windows locks. On Windows XP and older, the Windows service 'Terminal Services' should be enabled. If this service is disabled, locking KeePass when Windows locks might not work. This service isn't required on newer operating systems.
KeePass creates a temporary HTML file when printing password lists and showing print previews. This file is securely deleted when closing the database.
You must wait for the file being printed completely before closing KeePass (and close the print preview before closing KeePass), otherwise it could happen that the printing application blocks KeePass from deleting the file.
There is no way around the temporary file in the current printing system. If you want to write a plugin that directly sends the data to the printer, you can find a plugin development tutorial here: KeePass 2.x Plugin Development.
For estimating the quality/strength of a password, KeePass not only uses statistical methods (like checking which character ranges are used, repeating characters and differences), it also has a built-in list of common passwords and checks for patterns. When completing a common password or a repetition, the estimated quality can drop.
Details can be found on the Password Quality Estimation help page.
A few times it has been requested that a standard entry field for e-mail addresses is added (on the main tab page in the entry editing dialog). The short answer: an e-mail address field will not be added due to usability reasons. Now the long answer.
First of all, let's assume that most of the entries stored in KeePass contain information for logging in to websites. When you register an account for a website, you often have to specify a user name as well as an e-mail address. When you regularly log in later, you usually only need to provide either user name + password or e-mail + password (never user name + e-mail + password). Here the first part (which is either user name or e-mail) serves as identification: you tell the website who you are. The second part (password) provides authentication: you prove to the website that you're really the one who you claim to be.
There are various methods how KeePass can transfer data to
other applications. All of these methods by default assume that the content
of the user name field is used for identification. For example,
the default auto-type sequence of
an entry is
{USERNAME}{TAB}{PASSWORD}{ENTER}
, the default
KeeForm
configuration uses the user name, etc.
Now on the one hand some websites require an e-mail address instead
of a user name. On the other hand we want the default data transfer configuration
to work for most websites (such that the work that the user has to put
into the configuration is kept minimal and only needed for
websites using special login forms).
The solution is simple: instead of interpreting the 'User Name' field strictly as a field containing a user name, users should rather interpret it as a field in which the data required for identification is stored. This data can consist of a user name, an e-mail address or something else (e.g. an account number for an online banking website). By handling it like this, the default data transfer configuration will work for most websites, i.e. zero amount of work needs to be put into the configuration. If you had to provide both a user name and an e-mail address at registration time, the other information (which isn't required on a regular basis) can be stored e.g. in the notes field or a custom string field of the KeePass entry.
Now assume a separate e-mail field would be added. When users store both a user name and an e-mail address, KeePass cannot know which of the two is required for identification. So, in order to setup data transfer for the entry, users would be forced to choose which of the two fields should be used.
So, adding an e-mail field would be a step back in usability, because it forces users to put additional time into data transfer configuration. The current system ('User Name' containing identification information, without a separate e-mail field) doesn't require this, and thus is the better solution.
For users that are willing to manually configure the data transfer for each entry, there are multiple ways to get a separate e-mail address field. After switching to the 'Advanced' tab in the entry editing dialog, an e-mail address field can be added as custom string. If the field should appear on the main tab page of the dialog, the KPEntryTemplates plugin can be used.