IDs, Labels, Titles, Descriptions, and Interactivity
1. Introduction
Inkscape’s Object Properties controls allow you to assign information to individual objects within an SVG document. These controls can be accessed by selecting Object and then Object Properties… from the main Inkscape menu or by using the PC shortcut Shift+Ctrl+O.
At first glance, fields such as ID, Label, Title, and Description can look like different ways of naming an object. They are not.
These properties serve different purposes:
ID identifies an object technically within the SVG document.
Label gives the object a human-readable name inside Inkscape.
Title provides a descriptive name that can be exposed to users and accessibility tools.
Description provides additional explanatory information.
Other attributes can influence how the object behaves in browsers, scripts, CSS, accessibility systems, and interactive applications.
Understanding the difference between these properties is particularly useful when creating SVGs intended to function as more than static artwork—for example, interactive diagrams, maps, interfaces, educational graphics, navigation systems, or SVG-based image maps.
2. The SVG Object Model
Before examining the individual controls, it helps to understand what Inkscape is actually editing.
An SVG is not merely an image. It is an XML document containing objects.
For example, a simple SVG might conceptually contain:
<svg>
<rect id="building" />
<circle id="entrance" />
<path id="route" />
</svg>
Each object can have properties and attributes.
Inkscape provides a graphical interface for editing many of those properties without requiring you to edit the SVG source code manually.
This distinction is important:
An SVG object can simultaneously have a technical identifier, an Inkscape-specific display name, descriptive metadata, visual properties, and interactive behavior.
3. ID
The ID is one of the most important properties.
An ID is the object’s technical identifier within the SVG document.
For example:
building_01
might identify a building.
The resulting SVG could contain:
<rect id="building_01" /> What is the ID Used For?
The ID can be used by:
JavaScript
CSS
hyperlinks
SVG references
animation
scripting
external applications
accessibility systems
DOM manipulation
other SVG objects
automated processing
For example, JavaScript could locate an object using:
document.getElementById("building_01")
This is one reason IDs become extremely important when an SVG is being used as an interactive interface.
ID Naming Rules
IDs should be:
unique within the SVG
relatively short
descriptive
predictable
free of unnecessary spaces
preferably based on a consistent naming convention
For example:
building_01
building_02
building_03
is preferable to:
thing
thing2
newthingfinal
If you are building a large interactive SVG, a systematic naming convention becomes particularly valuable.
For example:
node_home
node_about
node_projects
node_contact
or:
map_building_01
map_building_02
map_building IDs should generally be treated as permanent technical identifiers
If JavaScript, CSS, hyperlinks, or another application depends on an ID, changing it can break those relationships.
Think of the ID as the object’s database key.
That analogy is particularly useful if you are designing SVGs that eventually interact with a database or a DAM.
4. Label
The Label is primarily a human-readable name for an object within Inkscape.
For example:
Main Entrance
could be the label associated with:
entrance_01
The distinction is:
ID:
entrance_01
Label:
Main Entrance
The ID is intended for machines.
The label is intended primarily for humans working inside Inkscape.
Why is the Label Useful?
Imagine an SVG containing 150 objects.
Without useful names, the Objects panel might contain objects with names that are difficult to distinguish.
Giving them meaningful labels makes the document considerably easier to manage.
For example:
Building A
Building B
Building C
Main Entrance
Parking Area
Emergency Exit
Information Center
This becomes especially useful when your SVG contains groups containing other objects.
Label Versus ID
It is perfectly reasonable for them to be different.
For example:
ID: building_17
Label: Administration Building
That is actually a good design.
The ID can remain stable and machine-friendly while the label can be changed for the convenience of the designer.
5. Title
The Title field is different from the Inkscape label.
A title is descriptive metadata associated with an SVG object.
It can be used to communicate what the object represents.
For example:
Administration Building
or:
Click to explore the administration building
The SVG specification supports titles through the <title> element.
Conceptually:
<g id="building_17">
<title>Administration Building</title>
</g>
The title can be useful to:
browsers
accessibility software
SVG viewers
scripts
document-processing software
Depending on how the SVG is displayed and how the browser/application handles SVG accessibility, the title may also contribute to a tooltip-like experience.
However, you should not assume that every SVG viewer will display the title in exactly the same way.
6. Description
The Description provides more detailed information about an object.
Think of the relationship this way:
ID
“What is this object called technically?”
Label
“What should I call this object while editing the document?”
Title
“What is this object?”
Description
“What additional information should I know about this object?”
For example:
ID:
building_library
Label:
Library
Title:
University Library
Description:
The main library building containing the research collections,
computer laboratory, and student study areas.
The description corresponds conceptually to the SVG <desc> element.
For example:
<g id="building_library">
<title>University Library</title>
<desc>
The main library building containing the research collections,
computer laboratory, and student study areas.
</desc>
</g>
Descriptions can therefore be useful for accessibility, documentation, and applications that extract information from SVG files.
7. The Four Fields Compared
A useful way to remember the differences is:
| Property | Primary purpose | Example |
|---|---|---|
| ID | Machine identifier | building_library |
| Label | Inkscape working name | Library |
| Title | Object title | University Library |
| Description | Additional information | Main research library... |
They are not redundant.
A single object could legitimately contain all four.
For example:
ID:
node_library
Label:
Library
Title:
Digital Library
Description:
Resources related to research, reference materials, and
digital collections. 8. Why IDs Matter for Interactivity
This is where these controls become particularly interesting.
Suppose you create an SVG map containing several buildings.
You could give each building a unique ID:
building_library
building_science
building_art
building_student_center
A web page could then interact with those objects.
For example, JavaScript could detect when the mouse enters an object:
document.getElementById("building_library")
The script could then:
change its appearance
display information
open a panel
display a card
reveal connected information
navigate somewhere
trigger an animation
This is one of the fundamental reasons SVG is capable of functioning as an interface rather than simply being a picture.
9. SVG Objects Can Become Interactive Regions
Suppose you create a campus map.
The visual appearance might be:
[Library]
[Science] [Art]
[Student Center]
Each building could actually be a separate SVG object.
The Library might have:
ID: library
Label: Library
Title: University Library
Description: Research and digital resources
The Science building could have:
ID: science
Label: Science Building
Title: Science and Technology
Description: Laboratories and technology programs
Now the SVG contains both:
visual information
semantic information
That distinction is extremely important.
A PNG only gives you pixels.
An SVG can contain objects that have identities and meaning.
10. Hyperlinks
SVG objects can also participate in hyperlinks.
For example, an SVG object could be associated with a destination such as:
https://example.com/library
The SVG can therefore function somewhat like an image map.
But SVG has a major advantage over a traditional raster image map: each region can itself be an actual vector object.
That means you can potentially:
highlight it
animate it
attach metadata to it
detect mouse events
change its appearance
connect it to another object
manipulate it with JavaScript
This is one of the reasons SVG is particularly well suited to interactive diagrams.
11. CSS and IDs
IDs can also be used by CSS.
For example:
#library {
opacity: 0.7;
}
could target the SVG object whose ID is:
library
A hover state could potentially be created with CSS as well:
#library:hover {
opacity: 1;
}
This allows the SVG to respond visually when the user moves the mouse over an object.
That is very different from a static image.
12. Mouseover Behavior
One particularly useful application involves moving the mouse over a hotspot and displaying an information card.
Conceptually, the SVG could contain:
ID: node_library
Title: Digital Library
Description: Explore the library resources
When the mouse enters that object, JavaScript could display a card.
The card might contain:
Digital Library
Research resources
Reference materials
Digital collections
[Explore]
When the mouse leaves the object, the card could disappear.
The SVG therefore acts as the visual interaction surface, while HTML/CSS/JavaScript can provide the interface around it.
13. Metadata Does Not Automatically Create Behavior
This is an important distinction.
Entering:
ID: library
Title: Digital Library
Description: Research resources
does not automatically create an interactive interface.
Those fields provide information.
Something still has to interpret that information.
For example:
SVG
↓
Object ID
↓
JavaScript detects object
↓
JavaScript retrieves metadata
↓
HTML card appears
The metadata provides the information.
JavaScript provides the behavior.
CSS provides the visual presentation.
HTML commonly provides the interface elements.
This separation makes sophisticated SVG interfaces possible.
14. Groups and Objects
SVG also allows objects to be grouped.
For example:
Library
├── Building
├── Door
├── Windows
├── Roof
└── Sign
Those individual objects can be grouped into a larger object.
The group itself can have an ID.
For example:
library
The individual components could have IDs such as:
library_building
library_door
library_window_01
library_window_02
library_sign
This creates a hierarchy.
That hierarchy can become extremely useful when creating complex interactive diagrams.
You could make the entire library respond as one interactive region while retaining separate objects for detailed manipulation.
15. Object Properties and Accessibility
One of the less obvious purposes of these fields is accessibility.
An SVG containing hundreds of shapes can be visually obvious to a sighted designer while being almost meaningless to software attempting to interpret it.
Semantic information helps bridge that gap.
For example:
ID:
exit_east
Title:
East Emergency Exit
Description:
Emergency exit located on the east side of the building.
This gives assistive technology and other software information about what the object represents.
Titles and descriptions can therefore be considered part of making an SVG understandable, rather than merely making it visually attractive.
16. Inkscape's Label is Not the Same Thing as a HTML Tooltip
This is an important potential source of confusion.
If you enter:
Label: Library
you should not assume that a web browser will automatically display:
Library
when the mouse moves over the object.
The Label is primarily an Inkscape document-management feature.
Similarly, entering a Description does not automatically create a sophisticated popup card.
If you want a custom interface such as:
┌─────────────────────────┐
│ Digital Library │
│ │
│ Research resources │
│ Digital collections │
│ │
│ Explore → │
└─────────────────────────┘
you would normally implement that behavior with web technologies.
17. A Practical Naming Strategy
If you intend to create interactive SVGs, I recommend separating technical naming from human-readable naming.
For example:
ID:
node_history
Label:
History
Title:
Historical Resources
Description:
Explore historical events, documents, and reference materials.
For another object:
ID:
node_science
Label:
Science
Title:
Science Resources
Description:
Explore science-related learning materials.
This gives you a clean separation between the machine-facing and human-facing information.
18. IDs as the Connection Between Systems
This becomes particularly powerful when SVG is connected to other applications.
Imagine you have a Digital Asset Manager (DAM) that contains an asset:
Asset ID: 1842
and that asset represents:
Science Resources
Your SVG could contain:
id="node_science"
Your web application could know that:
node_science → DAM asset 1842
The SVG does not necessarily need to contain the entire database record.
It can simply identify the object.
The application can then retrieve the appropriate information.
Conceptually:
SVG
│
│ node_science
▼
Application
│
│ asset lookup
▼
DAM
│
▼
Metadata / content
This is one reason I would strongly recommend treating IDs as deliberate architectural elements rather than arbitrary names.
19. Designing an Interactive SVG
If you know that an SVG will eventually become interactive, it is useful to think about it in layers.
Layer 1 — Visual
What does the object look like?
Examples:
color
stroke
fill
opacity
size
position
Layer 2 — Identity
What is the object?
Example:
ID: node_science Layer 3 — Human-readable metadata
What does the object represent?
Example:
Label: Science
Title: Science Resources
Description: Science learning materials Layer 4 — Interaction
What happens when the user interacts with it?
Examples:
hover
click
drag
zoom
navigation
popup
animation
Layer 5 — Application Data
What external information does the object connect to?
Examples:
URL
DAM asset
database record
Moodle activity
knowledge node
course
document
This layered approach prevents the SVG itself from becoming an unnecessarily complicated database.
20. A Worked Example
Suppose you create an SVG containing a node representing a course.
You might configure the object as follows:
ID:
course_career_exploration
Label:
Career Exploration
Title:
Career Exploration Course
Description:
An introductory learning experience covering career awareness,
research, and exploration.
The visual object might be a circle.
On the web page, JavaScript could detect:
course_career_exploration
When the mouse enters the circle, the application could display:
Career Exploration Course
Explore careers, identify interests, and investigate
possible career pathways.
[Open Course]
Clicking the button could then take the user to the appropriate destination.
The SVG provides the spatial representation.
The metadata identifies the object.
The application supplies the content.
The browser supplies the interaction.
21. Why This Is More Powerful Than a Conventional Image Map
A traditional image map generally starts with a raster image and defines clickable geometric regions over it.
SVG reverses the relationship.
The regions can actually be the artwork.
For example:
PNG
↓
image
↓
hotspot coordinates
versus:
SVG
↓
actual vector object
↓
ID
↓
metadata
↓
interaction
The second approach gives you much more information to work with.
A building isn’t merely a polygon sitting on top of an image.
The building itself can be an identifiable object.
22. The Most Important Concept
The most important thing to understand about these controls is that they allow you to turn an SVG from a collection of shapes into a collection of semantic objects.
A rectangle can simply be a rectangle.
Or it can be:
ID: node_04
Label: Architecture
Title: Architectural Resources
Description: Explore architectural concepts and examples.
Visually, it is still a rectangle.
Structurally, however, it has become an identifiable object with meaning.
That is the foundation for creating sophisticated SVG interfaces.
23. Recommended Practice
For interactive SVG projects, I would recommend:
Give important objects deliberate IDs.
Keep IDs unique.
Use a consistent ID naming convention.
Use Labels to make Inkscape’s object hierarchy understandable.
Use Titles to provide concise descriptions of objects.
Use Descriptions for additional semantic or accessibility information.
Do not rely on Labels, Titles, or Descriptions alone to create interaction.
Use JavaScript, CSS, and HTML when you need sophisticated behavior.
Treat IDs as stable identifiers if other systems will depend upon them.
Keep application data separate from the SVG when the data becomes substantial.
For a large interactive project, the distinction between identity, metadata, and behavior becomes extremely valuable.
A good mental model is:
ID = Who are you?
Label = What should I call you?
Title = What are you?
Description = Tell me more about you.
Interaction = What happens when I interact with you?
Destination = Where do you take me?
Once you start thinking about SVG objects this way, Inkscape’s Object Properties panel becomes considerably more interesting. It is not merely a collection of naming fields; it is one of the places where the boundary between graphic design and structured information becomes visible.
