RDP File Documentation

---

Technical details

Feature	Value
Full name	Remote Desktop Connection Settings File
File extension	.rdp
MIME type	application/x-rdp
Format type	Plain-text connection configuration
Line syntax	name:type:value (type = s, i or b)
Developer	Microsoft
Introduced	2001 (Remote Desktop, Windows XP)
Created by	Remote Desktop Connection client (mstsc.exe)
Encoding	Plain text (UTF-16 or UTF-8)
Magic number	None; files commonly start full address:s:
Contains a session?	No — settings only, no screen or session data
Saved password	Optional, DPAPI-encrypted and bound to the saving Windows user
Protocol	Remote Desktop Protocol (RDP)
Editable	Yes — right-click › Edit, or open in Notepad
Open standard	Partial — settings documented; protocol Microsoft-defined
macOS / iOS / Android opener	Windows App (formerly Microsoft Remote Desktop)
Linux opener	Remmina / FreeRDP
Related extensions	.rdpw, .rdg, .ica, .vnc
Specification	learn.microsoft.com/…/clients/rdp-files

What is an RDP file?

An RDP file is a Remote Desktop Connection settings file created by Microsoft’s Remote Desktop Connection client, mstsc.exe. The Remote Desktop Protocol itself dates to Windows XP (2001) and is built into Windows. The .rdp file is not the remote session and holds no screen content; it is purely configuration, a plain-text list of the parameters a client needs to open a session: the target host, the display resolution, which local devices to redirect, gateway details and the sign-in name.

Administrators hand out .rdp files so a user can reach a server or virtual-desktop host with one double-click, pre-loaded with the right settings. Because it is plain text, you can open one in Notepad to see or change exactly what it will do before you connect. That transparency matters for security, as later sections explain, since a hostile .rdp is dangerous precisely because of what its lines instruct the client to share.

The name:type:value line syntax

Every setting is one line in the form name:type:value. The middle field is a one-letter type code that tells the parser how to read the value: s for a string, i for an integer, and b for a binary value stored as hexadecimal. There are no sections, no brackets and no quoting; a line the client does not recognise is silently ignored, which is why files written by newer clients still open in older ones.

full address:s:rdp.example.com:3389
screen mode id:i:2
desktopwidth:i:1920
desktopheight:i:1080
session bpp:i:32
username:s:CONTOSO\jsmith
redirectclipboard:i:1
drivestoredirect:s:*
password 51:b:01000000d08c9ddf0115d1118c7a00c0…

The file is text, typically saved as UTF-16 (some tools write UTF-8). The practical way to identify one is that it opens with a recognisable key such as full address:s: or screen mode id:i:, since there is no binary signature to test for. Editing is just editing text: change rdp.example.com to a different host, or desktopwidth/desktopheight to a different resolution, and save.

Connection and display settings

The single required setting is full address:s:, the target host name or IP, optionally with a :port suffix (RDP’s default port is 3389). alternate shell:s: and remoteapplicationprogram:s: turn a full desktop into a single published app (RemoteApp). Display is governed by screen mode id:i: (1 = windowed, 2 = full-screen), desktopwidth and desktopheight for the resolution, use multimon:i: for multi-monitor spanning, and session bpp:i: for colour depth (16, 24 or 32 bits). smart sizing:i: scales the remote desktop to fit a resized window. None of these change the remote machine; they describe how the local client should present the session.

Resource redirection: the important lines

A block of redirect* settings decides which of your local resources are exposed to the remote host. These are the security-critical lines. redirectclipboard:i:1 shares your clipboard both ways. drivestoredirect:s:* mounts your local drives inside the remote session (a specific value like C:\; limits it to one drive). redirectprinters:i:1 maps your printers, redirectsmartcards:i:1 your smart cards, redirectcomports and usbdevicestoredirect your serial and USB devices, and audiomode:i: controls where sound plays.

The direction is what makes these matter. When you connect, redirection makes the remote computer able to read the local resources you enabled. Connecting to a machine you trust, that is convenient (drag a file from your PC into the session). Connecting to a machine you do not control, an enabled drivestoredirect or redirectclipboard hands your files and clipboard to whoever runs that host, which is exactly the mechanism the phishing attacks in the safety section abuse.

Gateway and authentication settings

To reach an internal host from outside the network, RDP uses an RD Gateway, configured with gatewayhostname:s: and gatewayusagemethod:i:; the client tunnels the RDP connection through that gateway over HTTPS. Identity settings include username:s: and domain:s:, which pre-fill the sign-in, and prompt for credentials on client:i:, which forces the local machine to gather credentials. authentication level:i: and enablecredsspsupport:i: govern server-identity verification and Network Level Authentication (NLA), the pre-session authentication that stops an unauthenticated client from ever reaching the logon screen. These lines set policy for the handshake; they do not carry the credentials themselves, apart from the optional saved-password field described next.

The saved password: DPAPI, not clear text

An .rdp can optionally store a password, but only as a password 51:b: line whose value is an encrypted blob, never clear text. The encryption is Windows DPAPI (the Data Protection API), keyed to the specific Windows user account that saved the file. Two consequences follow. First, the hex value is meaningless to anyone reading the text: it is not the password and cannot be reversed without that user’s keys. Second, the field does not travel: copy the file to another machine or another account and the saved password simply fails to decrypt, so the client prompts for it. This is why a shared .rdp template never usefully carries a password, and why you should still treat a file that claims to as untrusted rather than convenient.

Is an RDP file safe? Malicious .rdp attachments

The format is inert text, so the danger is not code execution, it is configuration abuse combined with social engineering. In documented 2024 campaigns, attackers emailed .rdp attachments crafted to connect to a server they controlled with redirection switched fully on: drivestoredirect:s:*, redirectclipboard:i:1, and often smart-card and device redirection as well. The moment a victim double-clicked and connected, their local drives, clipboard and devices were mounted on the attacker’s host, letting the attacker read files and harvest data directly, and in some cases stage further malware, without any exploit at all. The .rdp simply told the victim’s own trusted client to expose everything.

The defences are concrete. Treat an unexpected .rdp like any other attachment and do not open one you did not request. Before connecting, right-click the file and choose Edit, or open it in Notepad, and read three things: the full address (do you recognise the host?), the redirect* and drivestoredirect lines (is it trying to mount your drives or clipboard?), and any gateway host. Delete the file if the address is unfamiliar or the redirection is broader than you expect. The “unknown publisher” warning that appears on double-click is normal for any unsigned .rdp, including legitimate ones your IT team sends; it is not a guarantee of danger, but it is a prompt to confirm you trust the source before you continue. Because the whole file is readable, inspecting it first is both easy and the single most effective precaution.

References

• Microsoft Learn — Supported RDP file settings
• Microsoft Learn — Remote Desktop clients (Windows App)
• Remmina — Linux remote desktop client (FreeRDP)

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.