What Is AutoLISP and What Is It Used For in AutoCAD?

AutoLISP is a version of the LISP programming language adapted for AutoCAD. It was added to AutoCAD in the mid-1980s and has stayed almost unchanged since — which is remarkable for a piece of software.

Three properties made it this durable in the AutoCAD world:

It is interpreted, not compiled. The text file you write runs directly. You make a change, reload, and see the result in seconds. In a .NET add-in that loop takes minutes.

It lives inside the drawing. LISP code reaches the AutoCAD drawing database directly. It can select objects on screen, read their properties, change them, create new ones. It is not a separate application but an extension of the drawing environment.

It behaves like a command. You can bind a function you wrote to the command line so that it is indistinguishable from AutoCAD's built-in commands. From the user's point of view there is no difference between LINE and the QUICK-TITLE you wrote.

Put those three together and you get this: you can shape your own AutoCAD. Commands that match how your company works, checks that match your standards, automation that matches your drawing scheme.

What a `.lsp` file means

AutoLISP code sits in a plain text file with a .lsp extension. You can open and read it even in Notepad — one of my favourite things about LISP: the code is transparent, nobody can hand you a closed box.

Other extensions you may run into:

In practice you will work with .lsp. .fas and .vlx usually turn up when a software company sells you a tool without giving you its code.

Let's not keep it abstract; these are the jobs LISP is used for most in the field:

Layer and drawing scheme work. Creating layers, assigning colours and linetypes, pulling drawings that arrive from outside into your company standard. LISP's most classic use, and still where it is most productive.

Bulk edits. Changing the font of every selected text, deleting everything on a given layer, fixing the scale of all blocks. Jobs that take half a day by hand drop to seconds.

Attribute work. Reading, filling and exporting block attributes. Producing a bill of materials is usually most practical this way.

Custom drawing commands. Drawing something specific to your product with a single command: a standard connection detail, a section symbol, your company title block.

Plotting and output. Applying page setup settings and plotting in bulk. Printing every drawing in a folder to PDF with the same settings.

Data extraction. Collecting information from a drawing and writing it to a text or CSV file. The first automation of teams feeding data into an ERP is usually this one.

I answered the question "what exactly can be automated in AutoCAD" in more detail in a separate article: what can be automated in AutoCAD.

The easiest way to understand LISP is to think of it as "making AutoCAD type commands for you." Normally you type LINE at the command line, click two points, press Enter. LISP can do the same — but in your place, without mistakes, a hundred times a second.

Beyond that it can do two more things:

It can read the drawing database directly. Every object on screen — line, circle, text, block — is actually a data record. LISP can reach those records and answer questions like "how long is this line", "what does this text say", "which layer is this block on".

It can select in bulk. It can build selection sets on criteria like "select every circle on this layer", "find everything with a radius smaller than 5". Work that is near impossible by hand is a one-line matter in LISP.

Combine those two and things like this become possible: "walk every block in the drawing, read the attribute values, find the ones containing the project code, change all their layers and write a report." One command, a few seconds.

So what is Visual LISP?

A name you will meet often. Visual LISP is the shared name for two things added on top of AutoLISP:

1. A development environment (VLIDE). An editor that opens inside AutoCAD for writing code, running it line by line and debugging.
2. Extended functions. More modern access to objects, file operations, the ability to talk to external applications.

So Visual LISP is not a separate language — it is AutoLISP made more capable. Most people who say "I write LISP" today are actually using Visual LISP functions as well.

A note: in recent AutoCAD releases the VLIDE editor was removed and replaced by an official AutoLISP extension for Visual Studio Code. On the writing side you have moved to a modern editor; the language itself is the same.

I like LISP but it is not suited to every job. Knowing where it shines and where it stumbles is what lets you decide correctly.

Where it shines:

• Speed. The time from an idea to working code is measured in minutes. No alternative is this fast.
• Accessibility. No installation, no licence, no development environment to buy. Notepad and AutoCAD are enough.
• Transparency. The code is readable. You can look at what you did six months later; so can whoever comes after you.
• Closeness to the drawing environment. Selection, calling commands, asking the user for a point — these are natural in LISP and more laborious by other routes.

Where it stumbles:

• Error handling is weak. When something goes wrong LISP does not report it politely; it usually either stops or carries on incorrectly.
• Writing tests is practically impossible. There is no automated test infrastructure. That is a serious risk as the code grows.
• Large files become hard to maintain. A thousand-line LISP file is far harder to manage than a C# file of the same size.
• The interface is limited. If you want a user interface beyond simple boxes you will struggle.
• A quiet organisational risk. When the person who wrote the LISP leaves, the code is orphaned at most companies. I have seen this many times in the field.

That last item is the non-technical one that costs the most. A LISP library grows over the years, nobody documents it, the person who wrote it leaves, and what remains is a pile of files nobody dares touch.

This is the most frequent question, and the answer lies not in technical superiority but in sustainability. I start with this question: who will maintain this code and how long will it live?

That last row matters: LISP is an excellent exploration language. You try an idea in half an hour and see whether it works. If it does and it is going to be permanent, then you think about moving it to .NET.

I covered this decision, and how AI enters the equation, in more detail in AutoCAD automation: how I choose between LISP, .NET and AI.

The most productive way to learn LISP is not reading a book but solving a small, real job. I suggest this order:

1. Pick a problem. Something you do a few times a day, boring and rule-bound. Something modest like "create this layer and make its colour this" is ideal.

2. Set up your editor. On newer AutoCAD releases, Visual Studio Code plus the official AutoLISP extension is the right start. On older versions VLIDE is already inside AutoCAD.

3. Read existing code. There are tens of thousands of free LISP routines online. Download one, run it, then open it and read it. LISP's syntax looks odd at first (the parentheses!) but you get used to it within two days.

4. Make small changes. Taking a ready-made routine and changing a layer name teaches you far more than a first attempt at writing from scratch.

5. Define your own command. The most satisfying moment of the job is typing your own abbreviation at the command line and seeing something happen. I described how that is done, step by step, in adding a new command to AutoCAD with AutoLISP.

6. Automate the loading. You will want the routines you write to be ready every time AutoCAD opens. I gathered the ways of doing that in loading AutoLISP files and starting them automatically.

This question now comes up at every seminar, so let me answer it plainly: no, but it changed the equation.

Language models are genuinely good at writing LISP code. Describe a simple routine and the odds of getting working code back are high. That lowered the threshold for learning LISP considerably — you no longer have to memorise the syntax.

But two things did not change:

You need to know what to ask for. There is no such request as "fix the drawing." There is "convert every text on this layer to this font." Being able to write that description requires understanding the job itself.

You need to verify the generated code. LISP's weakest side was error handling, remember. Generated code inherits that weakness: it looks like it works and silently gives a wrong result in an edge case. And the changes it makes in the drawing cannot be undone.

My practical advice: generate the code, but try it on a copy of the drawing first. That one habit removes most of the risk of AI-assisted LISP writing.

What is AutoLISP? AutoLISP is a programming language that runs inside AutoCAD and lets users write their own commands. The code sits in a plain text .lsp file, runs without compilation once loaded into AutoCAD, and can reach the drawing database directly.

What is AutoLISP used for? Editing layers and drawing standards, bulk changes, reading and filling block attributes, creating drawing commands specific to a company's products, plotting in bulk with page setups, and extracting data from drawings. What they have in common is that they are rule-bound, repetitive jobs.

Is AutoLISP hard to learn? The syntax is unfamiliar at first because everything is written with parentheses, but the language is quite small. Downloading an existing routine and making small changes gets you moving far faster than trying to write from scratch.

Is AutoLISP still used? Yes. It has stayed almost unchanged since the 1980s and is supported in every AutoCAD release. For small, fast automation close to the drawing environment it is still the most practical route.

Should I use AutoLISP or .NET? AutoLISP for one-person, short-lived, drawing-editing work; .NET for work a team will use, that contains rules, connects to an external data source, or produces output that goes to production. The decision lies not in technical superiority but in who will maintain the code and how long it will live.

What is the difference between Visual LISP and AutoLISP? Visual LISP is not a separate language but an extended AutoLISP: it adds more modern object access, file operations and communication with external applications. It also offered a development environment called VLIDE; in newer AutoCAD releases that has been replaced by the official AutoLISP extension for Visual Studio Code.

How do I open and run a `.lsp` file? .lsp is a plain text file and can be opened and read in any text editor. To run it in AutoCAD you load it with the APPLOAD command; if you want it ready on every launch you need one of the automatic loading routes.

Is it safe to have AI write AutoLISP? It gives quite good results on simple routines, but the generated code inherits LISP's weak error handling: it can silently give a wrong result in edge cases, and changes in the drawing cannot be undone. Trying every generated routine on a copy of the drawing first is essential.

AutoLISP is the most direct automation door AutoCAD gives you. Small, fast, transparent, and living inside the drawing environment. On small, rule-bound jobs no alternative catches up with it.

Its limit is clear: as the code grows, as a team starts using it, and as it produces output that goes to production, LISP's weak sides — error handling, untestability, maintenance burden — come to the front. Once you cross that threshold, it is time to look at the .NET side.

But up to that threshold — and most offices' work sits below it — LISP is still the smartest choice.