Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
Privacy
|
Changes
|
Wishlist
cat a binary file, I get ‘PuTTYPuTTYPuTTY’ on my command line.cat a binary file, my window title changes to a nonsense string.putty.org your website?putty.org replaced its content with anti-vaccine propaganda in July 2025, was that because you were hacked or vandalised or taken over?the.earth.li and not chiark? Has your website been hacked?sha1sums / sha256sums / etc files on your download page don't match the binaries.This FAQ is published on the PuTTY web site, and also provided as an appendix in the manual.
PuTTY is a client program for the SSH network protocol, usually used to run terminal sessions over a network. It also supports running terminal sessions over a serial port, and a variety of older legacy network protocols such as Telnet, Rlogin, and SUPDUP.
These protocols are all used to run a remote session on a computer, over a network. PuTTY implements the client end of that session: the end at which the session is displayed, rather than the end at which it runs.
In really simple terms: you run PuTTY on a Windows machine, and tell it to connect to (for example) a Unix machine. PuTTY opens a window. Then, anything you type into that window is sent straight to the Unix machine, and everything the Unix machine sends back is displayed in the window. So you can work on the Unix machine as if you were sitting at its console, while actually sitting somewhere else.
These days, Windows comes with a version of OpenSSH as an optional component of the operating system, and its command prompt windows are much more like Unix terminals than they used to be. So it's true that if you want SSH on Windows, you can use OpenSSH in a Windows terminal, and not have to install PuTTY at all.
We're not going to try to persuade you that you shouldn't use OpenSSH in preference to PuTTY. PuTTY is free software, in the ‘no cost’ sense as well as the ‘freedom’ sense – we don't get more money by having more users. PuTTY and OpenSSH have different feature sets, and different ways of doing things, and it's entirely up to you which you prefer.
A few examples of things you might like about PuTTY:
~][thing] system, you always have to remember it's there even when you're not using it, to avoid triggering it with input you meant to send to the server. In PuTTY, the corresponding facilities (like reconfiguring port forwardings) are done using the GUI menus, and all keystrokes typed into the window consistently go to the server.
But if none of this impresses you, and you'd rather use Windows's version of OpenSSH, that's up to you.
Unix, of course, has always had OpenSSH, even before the Unix version of PuTTY existed. So this question has been relevant for much longer! When we first wrote the Unix port of PuTTY, people asked us why it was necessary. Partly the answer was that having the PuTTY code run on Unix too made it easier to develop in general (Unix had a wider range of better development and debugging facilities, and in my opinion, still does). But the same considerations as above also apply: on Unix too I use GUI PuTTY for my SSH connections, so that I never have to deal with that ~ business, and I use the Unix pterm for my local terminal sessions too.
In general, if you want to know if PuTTY supports a particular feature, you should look for it on the PuTTY web site. In particular:
Not at present, although section 4.33 in the documentation gives a method of achieving the same effect.
No, it doesn't.
Remembering your password is a bad plan for obvious security reasons: anyone who gains access to your machine while you're away from your desk can find out the remembered password, and use it, abuse it or change it.
In addition, it's not even possible for PuTTY to automatically send your password in a Telnet session, because Telnet doesn't give the client software any indication of which part of the login process is the password prompt. PuTTY would have to guess, by looking for words like ‘password’ in the session data; and if your login program is written in something other than English, this won't work.
In SSH, remembering your password would be possible in theory, but there doesn't seem to be much point since SSH supports public key authentication, which is more flexible and more secure. See chapter 8 in the documentation for a full discussion of public key authentication.
No, there isn't. And there won't be. Even if you write it yourself and send us the patch, we won't accept it.
Those annoying host key prompts are the whole point of SSH. Without them, all the cryptographic technology SSH uses to secure your session is doing nothing more than making an attacker's job slightly harder; instead of sitting between you and the server with a packet sniffer, the attacker must actually subvert a router and start modifying the packets going back and forth. But that's not all that much harder than just sniffing; and without host key checking, it will go completely undetected by client or server.
Host key checking is your guarantee that the encryption you put on your data at the client end is the same encryption taken off the data at the server end; it's your guarantee that it hasn't been removed and replaced somewhere on the way. Host key checking makes the attacker's job astronomically hard, compared to packet sniffing, and even compared to subverting a router. Instead of applying a little intelligence and keeping an eye on oss-security, the attacker must now perform a brute-force attack against at least one military-strength cipher. That insignificant host key prompt really does make that much difference.
If you're having a specific problem with host key checking – perhaps you want an automated batch job to make use of PSCP or Plink, and the interactive host key prompt is hanging the batch process – then the right way to fix it is to add the correct host key to the Registry in advance, or if the Registry is not available, to use the -hostkey command-line option (see section 3.11.3.22). That way, you retain the important feature of host key checking: the right key will be accepted and the wrong ones will not. Adding an option to turn host key checking off completely is the wrong solution and we will not do it.
If you have host keys available in the common known_hosts format, we have a script called kh2reg.py to convert them to a Windows .REG file, which can be installed ahead of time by double-clicking or using REGEDIT.
If you just manage and connect to a lot of servers with different host keys, you could consider using a ‘certification authority’, so that you only have to configure PuTTY once on each client machine to accept host keys from any of your servers in future. See section 4.19.4.
Not one that you'd want to use.
While much of the protocol and networking code can be made common between a client and server, to make a useful general-purpose server requires all sorts of fiddly new code like interacting with OS authentication databases and the like.
A special-purpose SSH server (called Uppity) can now be built from the PuTTY source code. But it's not usable as a general-purpose server. Its purpose is to be a test harness.
If someone else wants to use this as a basis for writing a general-purpose SSH server, they'd be perfectly welcome to, of course. But they would have to take responsibility for all of the security hardening that hasn't been done; we don't have time for that, and we don't have motivation. The code is available if anyone else wants to try it.
PuTTY is best known as a Windows tool, but it has an internal abstraction layer that permits it to run on other systems too. Here we discuss current, past and future possible ports.
Currently, release versions of PuTTY tools only run on Windows systems and Unix. The Windows version is provided in the form of executables, for both x86 and Arm based Windows systems. The Unix version is provided as source code (although at least some Linux distributions provide it pre-built).
Our standard Windows executable builds aim to run on all versions of Windows still in security support. Earlier versions might be supported if it's easy, but we don't promise to test them reliably. (For example, PuTTY 0.83 still runs on Windows XP – but the previous release 0.82 didn't.)
We do not have release-quality ports for any other systems at the present time. If anyone told you we had an Android port, or an iOS port, or any other port of PuTTY, they were mistaken. We don't.
There are some third-party ports to various platforms, mentioned on the Links page of our website.
As of 2026, I doubt that the core PuTTY team will ever finish one.
We've tried more than once. Around 2005 we attempted one in the form of a native Cocoa application, but it turned out to be very slow to redraw its window for some reason we never got to the bottom of.
In 2015, after porting the GTK front end to work with GTK 3, we began another attempt, based on making small changes to the GTK code and building it against the OS X Quartz version of GTK 3. This didn't have the speed issue, and came much closer to being finished. But unfortunately the Quartz GTK port seems to have bit-rotted: the last time I tried to build the Mac port, I couldn't even figure out how to install a GTK it would build with.
If anyone were interested in picking this up and finishing it, the TODO list in unix/main-gtk-application.c in the source code is a good place to start, and I'd be happy to provide advice and discussion.
We don't have one ourselves, for either Android or iOS.
The last time we checked, there was a third-party SSH client for the iPhone and iPod Touch called pTerm, which is apparently based on PuTTY. (This is nothing to do with our similarly-named pterm, which is a standalone terminal emulator.)
We don't know of any Android SSH application based on the PuTTY code. (There are Android SSH applications based on other implementations.)
No, it isn't. It would take a reasonable amount of rewriting for this to be possible, and since the PuTTY project itself doesn't believe in DLLs (they make installation more error-prone) none of us has taken the time to do it.
Most of the code cleanup work would be a good thing to happen in general, so if anyone feels like helping, we wouldn't say no.
See also the wishlist entry.
Probably your best bet is to use Plink, the command-line connection tool. If you can start Plink as a second Windows process, and arrange for your primary process to be able to send data to the Plink process, and receive data from it, through pipes, then you should be able to make SSH connections from your program.
By default, PuTTY has always announced its terminal type to SSH (and Telnet) servers as xterm, and tried to behave close enough to xterm itself that this works well enough.
PuTTY also supports some terminal control sequences not supported by the real xterm: notably the Linux console sequences that reconfigure the colour palette, and the title bar control sequences used by DECterm (which are different from the xterm ones; PuTTY supports both).
Since PuTTY was new, the xterm terminal type has split into many subtypes, so you may find that you benefit from upgrading to a terminal type such as xterm-256color to enable more features.
In modern versions of Linux, the terminal type database also includes a terminal type for PuTTY itself, so you could try setting the terminal type to ‘putty’! We didn't write that database entry, and don't know in detail what it includes or which version of PuTTY it was based on.
(We are sometimes asked why PuTTY doesn't use the ‘putty’ terminal type as default. Part of the reason is inertia. Another is that all the world's not Linux: I still worry that some servers will be confused by that terminal type. But perhaps one day we should switch over.)
On Windows, PuTTY stores most of its data (saved sessions, SSH host keys) in the Registry. The precise location is
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY
and within that area, saved sessions are stored under Sessions while host keys are stored under SshHostKeys.
PuTTY also requires a random number seed file, to improve the unpredictability of randomly chosen data needed as part of the SSH cryptography. This is stored by default in a file called PUTTY.RND; this is stored by default in the ‘Application Data’ directory, or failing that, one of a number of fallback locations. If you want to change the location of the random number seed file, you can put your chosen pathname in the Registry, at
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\RandSeedFile
You can ask PuTTY to delete all this data; see question A.8.2.
On Unix, PuTTY stores all of this data in a directory ~/.putty by default.
As of PuTTY 0.71, some lines of text in the terminal window are marked with a small copy of the PuTTY icon (as far as pixels allow).
This is to show trustworthiness. When the PuTTY icon appears next to a line of text, it indicates that that line of text was generated by PuTTY itself, and not generated by the server and sent to PuTTY.
Text that comes from the server does not have this icon, and we've arranged that the server should not be able to fake it. (There's no control sequence the server can send which will make PuTTY draw its own icon, and if the server tries to move the cursor back up to a line that already has an icon and overwrite the text, the icon will disappear.)
This lets you tell the difference between (for example) a legitimate prompt in which PuTTY itself asks you for your private key passphrase, and a fake prompt in which the server tries to send the identical text to trick you into telling it your private key passphrase.
As of PuTTY 0.71, if you use Plink for an interactive SSH session, then after the login phase has finished, it will present a final interactive prompt saying ‘Access granted. Press Return to begin session’.
This is another defence against servers trying to mimic the real authentication prompts after the session has started. When you pass through that prompt, you know that everything after it is generated by the server and not by Plink itself, so any request for your private key passphrase should be treated with suspicion.
In Plink, we can't use the defence described in section A.5.3: Plink is running in the terminal, so anything it can write into the terminal, the server could write in the same way after the session starts. And we can't just print a separator line without a pause, because then the server could simply move the cursor back up to it and overwrite it (probably with a brief flicker, but you might easily miss that). The only robust defence anyone has come up with involves this pause.
If you trust your server not to be abusive, you can turn this off. It will also not appear in various other circumstances where Plink can be confident it isn't necessary. See section 7.2.3.5 for details.
This is not a question you should be asking us.
PuTTY is a communications tool, for making connections to other computers. We maintain the tool; we don't administer any computers that you're likely to be able to use, in the same way that the people who make web browsers aren't responsible for most of the content you can view in them. We cannot help with questions of this sort.
If you know the name of the computer you want to connect to, but don't know what login name or password to use, you should talk to whoever administers that computer. If you don't know who that is, see the next question for some possible ways to find out.
Again, this is not a question you should be asking us. You need to read the manuals, or ask the administrator, of the computer you have connected to.
PuTTY does not process the commands you type into it. It's only a communications tool. It makes a connection to another computer; it passes the commands you type to that other computer; and it passes the other computer's responses back to you. Therefore, the precise range of commands you can use will not depend on PuTTY, but on what kind of computer you have connected to and what software is running on it. The PuTTY team cannot help you with that.
(Think of PuTTY as being a bit like a telephone. If you phone somebody up and you don't know what language to speak to make them understand you, it isn't the telephone company's job to find that out for you. We just provide the means for you to get in touch; making yourself understood is somebody else's problem.)
If you are unsure of where to start looking for the administrator of your server, a good place to start might be to remember how you found out the host name in the PuTTY configuration. If you were given that host name by e-mail, for example, you could try asking the person who sent you that e-mail. If your company's IT department provided you with ready-made PuTTY saved sessions, then that IT department can probably also tell you something about what commands you can type during those sessions. But the PuTTY maintainer team does not administer any server you are likely to be connecting to, and cannot help you with questions of this type.
There's no setting built in to PuTTY for this. But you can create a Windows shortcut to start PuTTY from, and set it as ‘Run Maximized’.
To run a PuTTY session saved under the name ‘mysession’, create a Windows shortcut that invokes PuTTY with a command line like
\path\name\to\putty.exe -load "mysession"
(Note: prior to 0.53, the syntax was @session. This is now deprecated and may be removed at some point.)
Use the command line putty -ssh host.name. Alternatively, create a saved session that specifies the SSH protocol, and start the saved session as shown in question A.6.4.
By default, copy and paste works similarly to the X Window System. You use the left mouse button to select text in the PuTTY window. The act of selection automatically copies the text to the clipboard: there is no need to press Ctrl-Ins or Ctrl-C or anything else. In fact, pressing Ctrl-C will send a Ctrl-C character to the other end of your connection (just like it does the rest of the time), which may have unpleasant effects. The only thing you need to do, to copy text to the clipboard, is to select it.
This default dates from the days when PuTTY was new, and its main target audience was ‘Unix expatriates’ – people who mostly used Unix desktop systems and were used to the X copy/paste mechanism, having to use Windows instead. The aim was ‘closest thing you can get to an xterm on Windows’.
If you prefer a more ‘Windows native’ interface for copy and paste, via keystrokes or menu actions, with nothing happening automatically on select, then you can reconfigure the behaviour flexibly in PuTTY's configuration. See section 4.11 for details.
To paste the clipboard contents into a PuTTY window, by default you click the right mouse button. If you have a three-button mouse and are used to X applications, you can configure pasting to be done by the middle button instead, but this is not the default because most Windows users don't have a middle button at all.
You can also paste by pressing Shift-Ins.
Most major features (e.g., public keys, port forwarding) are available through command line options. See section 3.11.3.
Not all features are accessible from the command line yet, although we'd like to fix this. In the meantime, you can use most of PuTTY's features if you create a PuTTY saved session, and then use the name of the saved session on the command line in place of a hostname. This works for PSCP, PSFTP and Plink (but don't expect port forwarding in the file transfer applications!).
PSCP is a command-line application, not a GUI application. If you run it without arguments, it will simply print a help message and terminate.
To use PSCP properly, run it from a Command Prompt window. See chapter 5 in the documentation for more details.
If PSCP is using the newer SFTP protocol (which is usual with most modern servers), this is straightforward; all filenames with spaces in are specified using a single pair of quotes in the obvious way:
pscp "local file" user@host:
pscp user@host:"remote file" .
However, if PSCP is using the older SCP protocol for some reason, things are more confusing. If you're specifying a file at the local end, you just use one set of quotes as you would normally do:
pscp "local filename with spaces" user@host:
pscp user@host:myfile "local filename with spaces"
But if the filename you're specifying is on the remote side, you have to use backslashes and two sets of quotes:
pscp user@host:"\"remote filename with spaces\"" local_filename
pscp local_filename user@host:"\"remote filename with spaces\""
Worse still, in a remote-to-local copy you have to specify the local file name explicitly, otherwise PSCP will complain that they don't match (unless you specified the -unsafe option). The following command will give an error message:
c:\>pscp user@host:"\"oo er\"" .
warning: remote host tried to write to a file called 'oo er'
when we requested a file called '"oo er"'.
Instead, you need to specify the local file name in full:
c:\>pscp user@host:"\"oo er\"" "oo er"
That isn't how you're supposed to use the Colours panel.
During the course of a session, PuTTY potentially uses all the colours listed in the Colours panel. It's not a question of using only one of them and you choosing which one; PuTTY will use them all. The purpose of the Colours panel is to let you adjust the appearance of all the colours. So to change the colour of the cursor, for example, you would select ‘Cursor Colour’, press the ‘Modify’ button, and select a new colour from the dialog box that appeared. Similarly, if you want your session to appear in green, you should select ‘Default Foreground’ and press ‘Modify’. Clicking on ‘ANSI Green’ won't turn your session green; it will only allow you to adjust the shade of green used when PuTTY is instructed by the server to display green text.
You almost certainly need to change the ‘Use background colour to erase screen’ setting in the Terminal panel. If there is too much black space (the commoner situation), you should enable it, while if there is too much colour, you should disable it. (See section 4.3.5.)
Some types of firewall, and almost any router doing Network Address Translation (NAT, also known as IP masquerading), will forget about a connection through them if the connection does nothing for too long. This will cause the connection to be rudely cut off when contact is resumed.
You can try to combat this by telling PuTTY to send keepalives: packets of data which have no effect on the actual session, but which reassure the router or firewall that the network connection is still active and worth remembering about.
Keepalives don't solve everything, unfortunately; although they cause greater robustness against this sort of router, they can also cause a loss of robustness against network dropouts. See section 4.14.1 in the documentation for more discussion of this.
This is a Windows problem, not a PuTTY problem. The timeout value can't be set on per application or per session basis. To increase the TCP timeout globally, you need to tinker with the Registry.
On Windows 95, 98 or ME, the registry key you need to create or change is
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\
MSTCP\MaxDataRetries
(it must be of type DWORD in Win95, or String in Win98/ME). (See MS Knowledge Base article 158474 for more information.)
On Windows NT, 2000, or XP, the registry key to create or change is
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\
Parameters\TcpMaxDataRetransmissions
and it must be of type DWORD. (See MS Knowledge Base articles 120642 and 314053 for more information.)
Set the key's value to something like 10. This will cause Windows to try harder to keep connections alive instead of abandoning them.
cat a binary file, I get ‘PuTTYPuTTYPuTTY’ on my command line.Don't do that, then.
This is designed behaviour; when PuTTY receives the character Control-E from the remote server, it interprets it as a request to identify itself, and so it sends back the string ‘PuTTY’ as if that string had been entered at the keyboard. Control-E should only be sent by programs that are prepared to deal with the response. Writing a binary file to your terminal is likely to output many Control-E characters, and cause this behaviour. Don't do it. It's a bad plan.
To mitigate the effects, you could configure the answerback string to be empty (see section 4.3.7); but writing binary files to your terminal is likely to cause various other unpleasant behaviour, so this is only a small remedy.
cat a binary file, my window title changes to a nonsense string.Don't do that, then.
It is designed behaviour that PuTTY should have the ability to adjust the window title on instructions from the server. Normally the control sequence that does this should only be sent deliberately, by programs that know what they are doing and intend to put meaningful text in the window title. Writing a binary file to your terminal runs the risk of sending the same control sequence by accident, and cause unexpected changes in the window title. Don't do it.
No, it doesn't. PuTTY just doesn't display the password you type, so that someone looking at your screen can't see what it is.
Unlike the Windows login prompts, PuTTY doesn't display the password as a row of asterisks either. This is so that someone looking at your screen can't even tell how long your password is, which might be valuable information.
If you've already tried all the relevant options in the PuTTY Keyboard panel, you may need to mail the PuTTY maintainers and ask.
It is not usually helpful just to tell us which application, which server operating system, and which key isn't working; in order to replicate the problem we would need to have a copy of every operating system, and every application, that anyone has ever complained about.
PuTTY responds to function key presses by sending a sequence of control characters to the server. If a function key isn't doing what you expect, it's likely that the character sequence your application is expecting to receive is not the same as the one PuTTY is sending. Therefore what we really need to know is what sequence the application is expecting.
The simplest way to investigate this is to find some other terminal environment, in which that function key does work; and then investigate what sequence the function key is sending in that situation. One reasonably easy way to do this on a Unix system is to type the command cat, and then press the function key. This is likely to produce output of the form ^[[11~. You can also do this in PuTTY, to find out what sequence the function key is producing in that. Then you can mail the PuTTY maintainers and tell us ‘I wanted the F1 key to send ^[[11~, but instead it's sending ^[OP, can this be done?’, or something similar.
You should still read the Feedback page on the PuTTY website (also provided as appendix B in the manual), and follow the guidelines contained in that.
In PuTTY 0.78, the ‘Private key file for authentication’ control, where you specify a .PPK file for SSH public key authentication, moved to a new ‘Credentials’ panel in the configuration dialog. You can find this by opening the ‘SSH’ category in the tree view on the left, then opening the ‘Auth’ subcategory under that, then clicking on ‘Credentials’. On this page you'll find the ‘Browse...’ button you need to select a .PPK file for authentication, as described in section 4.22.1.
(This control had previously been on the ‘Auth’ panel since public key authentication was first released in 2002, so many online how-to guides still describe it there. The configuration controls were reorganised to make room for features added in 0.78, such as OpenSSH certificates.)
It depends on whether you trust that PC. If you don't trust the public PC, don't use PuTTY on it, and don't use any other software you plan to type passwords into either. It might be watching your keystrokes, or it might tamper with the PuTTY binary you download. There is no program safe enough that you can run it on an actively malicious PC and get away with typing passwords into it.
If you do trust the PC, then it's probably OK to use PuTTY on it (but if you don't trust the network, then the PuTTY download might be tampered with, so it would be better to carry PuTTY with you on a USB stick).
PuTTY will leave some Registry entries, and a random seed file, on the PC (see question A.5.2). Windows 7 and up also remember some information about recently launched sessions for the ‘jump list’ feature.
If you are using PuTTY on a public PC, or somebody else's PC, you might want to clean this information up when you leave. You can do that automatically, by running the command putty -cleanup. See section 3.11.2 in the documentation for more detail. (Note that this only removes settings for the currently logged-in user on multi-user systems.)
If PuTTY was installed from the installer package, it will also appear in ‘Add/Remove Programs’. Current versions of the installer do not offer to remove the above-mentioned items, so if you want them removed you should run putty -cleanup before uninstalling.
VirtualLock() to stop private keys being written to disk?
Unfortunately not. The VirtualLock() function in the Windows API doesn't do a proper job: it may prevent small pieces of a process's memory from being paged to disk while the process is running, but it doesn't stop the process's memory as a whole from being swapped completely out to disk when the process is long-term inactive. And Pageant spends most of its time inactive.
The free-of-charge ‘PuTTY’ application at this link is published and maintained by us. The copy there is the latest release, usually updated within a few days of us publishing it on our own website.
There have been other copies of PuTTY on the store, some looking quite similar, and some charging money. Those were uploaded by other people, and we can't guarantee anything about them.
The first version we published to the Microsoft Store was 0.76 (some time after its initial release on our website).
putty.org your website?No, it isn't, and it never has been. We don't own it; we can't control it; we have no responsibility for anything it does.
putty.org was set up by an opportunist selling a competing SSH client for money, who initially used it to interpose adverts for their own commercial SSH implementation in the course of providing a link to our free one. Then in July 2025 it changed its content to host anti-vaccine propaganda. We have no idea what it might do next.
Since the start of PuTTY, the real PuTTY web site, run by the PuTTY team, has always been at https://www.chiark.greenend.org.uk/~sgtatham/putty/.
We don't recommend that anyone use putty.org as a convenient redirector, or indeed any other convenient landing page that is not ours. There are a few others, some set up in entirely good faith, but you never know.
As of August 2025, we have registered putty.software and made that into an official landing page. If you'd like a short easy URL, that's the one to use, especially if we move the main website there in future.
putty.org replaced its content with anti-vaccine propaganda in July 2025, was that because you were hacked or vandalised or taken over?
No, because putty.org was never ours in the first place (see question A.9.1). It wasn't stolen from us, or bought from us. The same person who owned it all along decided to change its content.
Every release of PuTTY embeds a URL to the web site, via the ‘Visit web site’ button in the About box.
The real website is where PuTTY itself says it is.
If you download a cryptographically signed version of PuTTY – either a Windows binary signed with Simon Tatham's Authenticode key, or anything signed with the PuTTY team's GPG key – then you can confirm that the URL embedded in that copy is the one that the developers themselves endorse as the true web site.
As of August 2025, putty.software is a second web location owned by us, the PuTTY developers. That too is endorsed by signed copies of PuTTY, via being mentioned in this FAQ section of the help file.
If we move the web site later – as of August 2025, our plan is to move it from the chiark domain name to once the latter is generally recognised as legitimate – then we will keep a redirection of some kind at the old location, so that it continues to work. Both URLs will continue to be legitimate places to find PuTTY, whichever is currently preferred.
the.earth.li and not chiark? Has your website been hacked?
We haven't been hacked: links to the.earth.li are legit. The files for released versions of PuTTY are hosted on a different server from the web pages, for bandwidth reasons.
The download site the.earth.li is hosted by Mythic Beasts, and we're very grateful to them!
No, thank you. We've got one: putty.software.
For a long time, this FAQ entry said that we were happy with the site where it is. However, in 2025, as a result of some media attention to putty.org, it became clear that search engines these days seem to prefer short whole domain names over user subdirectories on a larger server.
So we registered a domain name ourselves. As of August 2025, putty.software is a small landing page, similar to third-party redirectors except not run by a third party. After we've got the word out and built some trust, the plan is to move the whole PuTTY site there and turn the old chiark site into a redirection.
We already have some, thanks.
Only if the content of your web page is of definite direct interest to PuTTY users. If your content is unrelated, or only tangentially related, to PuTTY, then the link would simply be advertising for you.
This is still true even if you offer to pay us. We aren't interested in trading links for money, and we certainly aren't interested in trading links for other links. If we don't want to link to you for free, then we probably won't want to link to you at all.
If you have software based on PuTTY, or specifically designed to interoperate with PuTTY, or in some other way of genuine interest to PuTTY users, then we will probably be happy to add a link to you on our Links page. And if you're running a particularly valuable mirror of the PuTTY web site, we might be interested in linking to you from our Mirrors page.
Primarily, trust. PuTTY is a security product, and as such it is particularly important to guard the code and the web site against unauthorised modifications which might introduce subtle security flaws. Therefore, we prefer that the Git repository, web site and FTP site remain where they are, under the direct control of system administrators we know and trust personally.
Large organisations seem less trustworthy to us because they have a lot of employees, any of whom could attempt an insider attack; because management can change or companies can be bought out, and a benign company today could become a malicious one tomorrow.
Github in particular already seems like a dangerously large single point of failure. I'd rather contribute to the Internet being distributed than contribute to it being centralised. In addition, the Github software isn't itself free, so although you can export the actual source repository itself at any time (every ‘git clone’ does that), you're locked in once all your other metadata (issues, pull requests etc) is stored in Github's format on Github's systems.
I know that if you have a Github presence already, it would be most convenient for you if everyone else was on Github too so that you could interact with them all in the same easy way. Sorry about that. But that seductive ease of use is how large companies attract a large user base to monetise or exploit later, and we don't want to participate in that any more than we have to.
Because you're not a member of the PuTTY core development team. The putty-bugs mailing list is not a general newsgroup-like discussion forum; it's a contact address for the core developers, and an internal mailing list for us to discuss things among ourselves. If we opened it up for everybody to subscribe to, it would turn into something more like a newsgroup and we would be completely overwhelmed by the volume of traffic. It's hard enough to keep up with the list as it is.
There isn't one, that we know of.
If someone else wants to set up a mailing list or other forum for PuTTY users to help each other with common problems, that would be fine with us, though the PuTTY team would almost certainly not have the time to read it.
Please, please don't feel you have to. PuTTY is completely free software, and not shareware. We think it's very important that everybody who wants to use PuTTY should be able to, whether they have any money or not; so the last thing we would want is for a PuTTY user to feel guilty because they haven't paid us any money. If you want to keep your money, please do keep it. We wouldn't dream of asking for any.
Having said all that, if you still really want to give us money, we won't argue :-) The easiest way for us to accept donations is if you send money to <anakin@pobox.com> using PayPal (www.paypal.com). If you don't like PayPal, talk to us; we can probably arrange some alternative means.
Small donations (tens of dollars or tens of euros) will probably be spent on beer or curry, which helps motivate our volunteer team to continue doing this for the world. Larger donations will be spent on something that actually helps development, if we can find anything (perhaps new hardware, or a new version of Windows), but if we can't find anything then we'll just distribute the money among the developers. If you want to be sure your donation is going towards something worthwhile, ask us first. If you don't like these terms, feel perfectly free not to donate. We don't mind.
Yes. For most things, you need not bother asking us explicitly for permission; our licence already grants you permission.
See section B.9 for more details.
No!
A vendor of physical security products (e.g. locks) might plausibly be willing to accept financial liability for a product that failed to perform as advertised and resulted in damage (e.g. valuables being stolen). The reason they can afford to do this is because they sell a lot of units, and only a small proportion of them will fail; so they can meet their financial liability out of the income from all the rest of their sales, and still have enough left over to make a profit. Financial liability is intrinsically linked to selling your product for money.
There are two reasons why PuTTY is not analogous to a physical lock in this context. One is that software products don't exhibit random variation: if PuTTY has a security hole (which does happen, although we do our utmost to prevent it and to respond quickly when it does), every copy of PuTTY will have the same hole, so it's likely to affect all the users at the same time. So even if our users were all paying us to use PuTTY, we wouldn't be able to simultaneously pay every affected user compensation in excess of the amount they had paid us in the first place. It just wouldn't work.
The second, much more important, reason is that PuTTY users don't pay us. The PuTTY team does not have an income; it's a volunteer effort composed of people spending their spare time to try to write useful software. We aren't even a company or any kind of legally recognised organisation. We're just a bunch of people who happen to do some stuff in our spare time.
Therefore, to ask us to assume financial liability is to ask us to assume a risk of having to pay it out of our own personal pockets: out of the same budget from which we buy food and clothes and pay our rent. That's more than we're willing to give. We're already giving a lot of our spare time to developing software for free; if we had to pay our own money to do it as well, we'd start to wonder why we were bothering.
Free software fundamentally does not work on the basis of financial guarantees. Your guarantee of the software functioning correctly is simply that you have the source code and can check it before you use it. If you want to be sure there aren't any security holes, do a security audit of the PuTTY code, or hire a security engineer if you don't have the necessary skills yourself: instead of trying to ensure you can get compensation in the event of a disaster, try to ensure there isn't a disaster in the first place.
If you really want financial security, see if you can find a security engineer who will take financial responsibility for the correctness of their review. (This might be less likely to suffer from the everything-failing-at-once problem mentioned above, because such an engineer would probably be reviewing a lot of different products which would tend to fail independently.) Failing that, see if you can persuade an insurance company to insure you against security incidents, and if the insurer demands it as a condition then get our code reviewed by a security engineer they're happy with.
If your form contains any clause along the lines of ‘the undersigned represents and warrants’, we're not going to sign it. This is particularly true if it asks us to warrant that PuTTY is secure; see question A.9.13 for more discussion of this. But it doesn't really matter what we're supposed to be warranting: even if it's something we already believe is true, such as that we don't infringe any third-party copyright, we will not sign a document accepting any legal or financial liability. This is simply because the PuTTY development project has no income out of which to satisfy that liability, or pay legal costs, should it become necessary. We cannot afford to be sued. We are assuring you that we have done our best; if that isn't good enough for you, tough.
The existing PuTTY licence document already gives you permission to use or distribute PuTTY in pretty much any way which does not involve pretending you wrote it or suing us if it goes wrong. We think that really ought to be enough for anybody.
See also question A.9.16 for another reason why we don't want to do this sort of thing.
We could, in principle, but it isn't clear what use it would be. If you think there's a serious chance of one of the PuTTY copyright holders suing you (which we don't!), you would presumably want a signed notice from all of them; and we couldn't provide that even if we wanted to, because many of the copyright holders are people who contributed some code in the past and with whom we subsequently lost contact. Therefore the best we would be able to do even in theory would be to have the core development team sign the document, which wouldn't guarantee you that some other copyright holder might not sue.
See also question A.9.16 for another reason why we don't want to do this sort of thing.
Not unless there's an incredibly good reason.
We are generally unwilling to set a precedent that involves us having to enter into individual agreements with PuTTY users. We estimate that we have literally millions of users, and we absolutely would not have time to go round signing specific agreements with every one of them. So if you want us to sign something specific for you, you might usefully stop to consider whether there's anything special that distinguishes you from 999,999 other users, and therefore any reason we should be willing to sign something for you without it setting such a precedent.
If your company policy requires you to have an individual agreement with the supplier of any software you use, then your company policy is simply not well suited to using popular free software, and we urge you to consider this as a flaw in your policy.
Yes and no.
If what you want is an assurance that some current version of PuTTY which you've already downloaded will remain free, then you already have that assurance: it's called the PuTTY Licence. It grants you permission to use, distribute and copy the software to which it applies; once we've granted that permission (which we have), we can't just revoke it.
On the other hand, if you want an assurance that future versions of PuTTY won't be closed-source, that's more difficult. We could in principle sign a document stating that we would never release a closed-source PuTTY, but that wouldn't assure you that we would keep releasing open-source PuTTYs: we would still have the option of ceasing to develop PuTTY at all, which would surely be even worse for you than making it closed-source! (And we almost certainly wouldn't want to sign a document guaranteeing that we would actually continue to do development work on PuTTY; we certainly wouldn't sign it for free. Documents like that are called contracts of employment, and are generally not signed except in return for a sizeable salary.)
If we were to stop developing PuTTY, or to decide to make all future releases closed-source, then you would still be free to copy the last open release in accordance with the current licence, and in particular you could start your own fork of the project from that release. If this happened, I confidently predict that somebody would do that, and that some kind of a free PuTTY would continue to be developed. There's already precedent for that sort of thing happening in free software. We can't guarantee that somebody other than you would do it, of course; you might have to do it yourself. But we can assure you that there would be nothing preventing anyone from continuing free development if we stopped.
(Finally, we can also confidently predict that if we made PuTTY closed-source and someone made an open-source fork, most people would switch to the latter. Therefore, it would be pretty stupid of us to try it.)
Some people have asked us for an Export Control Classification Number (ECCN) for PuTTY. We don't know whether we have one, and as a team of free software developers based in the UK we don't have the time, money, or effort to deal with US bureaucracy to investigate any further. We believe that PuTTY falls under 5D002 on the US Commerce Control List, but that shouldn't be taken as definitive. If you need to know more you should seek professional legal advice. The same applies to any other country's legal requirements and restrictions.
Similarly, some people have asked us for FIPS certification of the PuTTY tools. Unless someone else is prepared to do the necessary work and pay any costs, we can't provide this.
We periodically receive requests like this, from organisations which have apparently sent out a form letter to everyone listed in their big spreadsheet of ‘software vendors’ requiring them all to answer some long list of questions about supported OS versions, paid support arrangements, compliance with assorted local regulations we haven't heard of, contact phone numbers, and other such administrivia. Many of the questions are obviously meaningless when applied to PuTTY (we don't provide any paid support in the first place!), most of the rest could have been answered with only a very quick look at our website, and some we are actively unwilling to answer (we are private individuals, why would we want to give out our home phone numbers to large corporations?).
We don't make a habit of responding in full to these questionnaires, because we are not a software vendor.
A software vendor is a company to which you are paying lots of money in return for some software. They know who you are, and they know you're paying them money; so they have an incentive to fill in your forms and questionnaires, to research any local regulations you cite if they don't already know about them, and generally to provide every scrap of information you might possibly need in the most convenient manner for you, because they want to keep being paid.
But we are a team of free software developers, and that means your relationship with us is nothing like that at all. If you once downloaded our software from our website, that's great and we hope you found it useful, but it doesn't mean we have the least idea who you are, or any incentive to do lots of unpaid work to support our ‘relationship’ with you.
It's not that we are unwilling to provide information. We put as much of it as we can on our website for your convenience, and if you actually need to know some fact about PuTTY which you haven't been able to find on the website (and which is not obviously inapplicable to free software in the first place) then please do ask us, and we'll try to answer as best we can. But we put up the website and this FAQ precisely so that we don't have to keep answering the same questions over and over again, so we aren't prepared to fill in completely generic form-letter questionnaires for people who haven't done their best to find the answers here first.
If you work for an organisation which you think might be at risk of making this mistake, we urge you to reorganise your list of software suppliers so that it clearly distinguishes paid vendors who know about you from free software developers who don't have any idea who you are. Then, only send out these mass mailings to the former.
sha1sums / sha256sums / etc files on your download page don't match the binaries.People report this every so often, and usually the reason turns out to be that they've matched up the wrong checksums file with the wrong binaries.
The PuTTY download page contains more than one version of the software. There's a latest release version; there are the development snapshots; and when we're in the run-up to making a release, there are also pre-release builds of the upcoming new version. Each one has its own collection of binaries, and its own collection of checksums files to go with them.
So if you've downloaded the release version of the actual program, you need the release version of the checksums too, otherwise you will see a mismatch. Similarly, the development snapshot binaries go with the development snapshot checksums, and so on. (We've colour-coded the download page in an effort to reduce this confusion a bit.)
Another thing to watch out for: as of 0.71, executables like putty.exe come in two flavours for each platform: the standalone versions on the website, each of which contains embedded help, and the versions installed by the installer, which use a separate help file also in the installer. We provide checksums for both; the latter are indicated with ‘(installer version)’ after the filename.
If you have double-checked all that, and you still think there's a real mismatch, then please send us a report carefully quoting everything relevant:
No, it isn't. PuTTY is almost completely composed of code written from scratch for PuTTY. As of 2026, PuTTY and OpenSSH have no code in common as far as I know.
(In the past, there has been at least one case of both tools sharing the same piece of third-party code, but not in up-to-date versions.)
No, it does not. PuTTY does not use any AI or LLM during its operation. No code implementing an AI or LLM system is included in PuTTY itself, and also, no AI or LLM system elsewhere on the Internet is consulted by PuTTY when it runs.
PuTTY aims to be reliable, predictable and efficient in its operation. The 2020s style of AI is bad at all of these things, especially ‘efficient’.
PuTTY does not collect any data from its users to communicate to any host run by the PuTTY developers, for LLM training or for any other purpose. (See appendix I for more detailed information about what information PuTTY does store and transmit, but the short answer is, it only stores information necessary to do its job, and only talks over the network to the servers you told it to connect to.)
Of course, after you use PuTTY to connect to a server, that server may choose to do AI-related operations, or to collect the data from your session. PuTTY can do nothing about that (or even detect it happening), and if you're concerned about it, you'll have to consult whoever runs your server.
It's the name of a popular SSH and Telnet client. Any other meaning is in the eye of the beholder. It's been rumoured that ‘PuTTY’ is the antonym of ‘getty’, or that it's the stuff that makes your Windows useful, or that it's a kind of plutonium Teletype. We couldn't possibly comment on such allegations.
Exactly like the English word ‘putty’, which we pronounce /ˈpʌti/.