Better (human-readable) asset name


  • Use page name as prefix of asset name
  • Let user specify an asset name (a little inconvenient though)

An alternative is to support renaming an asset easily.

Yes please … option to rename is good. And automatically change all referred links.

As an extra plus remove the need to point to the assets folder in the link. Assets folder is already defined so needless to define it explicitly in every link.

It’s because you are not forced to use /assets, you can place files in other folders and still reference them. If /assets bothers you, you can place assets in a folder like /a, but you would need to update the reference manually at the moment.

Install the Logseq-localassets-plugin and use the command /Embed non local asset file.

You can then embed any file outside the assets folder through an explorer window.

It solves a different problem. My use cases are mainly copy-pasting images into Logseq. Another point is that local links are fragile, and I’d rather let Logseq own all the assets if possible.

You can use the same plugin and use /Embed file from asset folder and select the file from the asset folder as well.

That was my point … make it a setting and assume that folder. That would also make transitions to another computer (folderstructure) much easier. There is no need to add it in the link.

This is technically possible with custom.js.

Copy the below to your custom.js file, and with a hiccup (e.g. img file), you can insert a “universal” image using [:img {:src "../assets/img.png" :class universal}] and the image should show up even on another computer.

const observer = new top.MutationObserver(()=>{
const graph = logseq.api.get_current_graph();
let currPath = document.querySelector(".universal");
if (currPath) {
currPath = graph.path + "/" + currPath.src.substring(currPath.src.indexOf("/assets"));
document.querySelector(".universal").src = currPath;

observer.observe(top.document.getElementById("app-container"), {
    attributes: false,
    childList: true,
    subtree: true,

But you may want to have multiple top level folders like /video, /pdf and so on instead of /assets.

Yes … and then it is a conscious choice you make. But why include assets as it is now?

It’s not that it’s not possible to use /assets as the root folder for links to local files, but then you would need to explain to users that there is a (Unix) syntax to go up of one level in links and that they can use that every time they want to refer to something outside the default folder:


What’s really missing is a way to change the default behavior when adding new asset, like changing the default folder or choose a custom one each time.

I can totally see users adopt something like /images, /videos etc instead of /assets if it was made easy from Logseq UI.

hmmm if so, the file must be first put in logseq folder manually. I mean I just want to paste into logseq, and let Logseq store it and name it. e.g., for screenshots, this will be helpful.

Well, but it seems a good wordaround though

No need to do that. I personally am happy with everything in one folder but don’t see the need to add the path “…/assets/link_to_file.png” in the link. Just use [[link_to_file.png]]. We don’t have to link to “…/pages/” to link to a page … so why would we need to do that for assets. It is inconsistant. And it is highly unlikely you have the same names (page and file) as files always have extensions.

That would be the default behaviour. The people who would like to have multiple folders are probably the ones you do not have to explain the unix syntax to go up or down in folder structure. But / should be assets (or configurable).

Logseq could easily show a folder list of existing folders in the assets folder if a file is dropped in logseq to make the user choose where to store his file. If no folders are found (default) it is just added to assets.

I understand where you are coming from but let me clarify some things:

  • Pages are generated by Logseq, they have unique names and by default are placed in /pages but you can move them around, Logseq will always recognize them but you need to keep unique names.
  • Assets can have whatever name they want and even reuse the same name if files are in different folders. This is because you may want to move/link a preexisting folders with your files inside /assets and those files may be organized in folders and their names not being unique.
  • The [[wikilink]] syntax works well with unique names from a precise namespace (i.e. Markdown/Org files inside the graph folder), while for images and other file types it is more convenient (and portable) to use standard Markdown syntax.

Since syntax could often be annoying, may I suggest the following macro?

"png" "![](../assets/$1.png)"

It will let you to just type:

{{png example}}

but when the block is not in edit mode Logseq will just render it like you wrote:


this macro makes much sense if you use a lot of PNG images and you want to get rid of the .png too; you can define other macros for other formats and even set it to look at folders other than /assets, or you can just define a {{image ...}} macro.

Edit: oooh I think I have found a very useful (at least for me) variant of the above:

"current" "![](../assets/<%current page%>/$1)"

that let me refer assets to the current page if I have placed them in /assets/[[Page Name]].

So if I have images numbered I can have something like this:

{{current 01.png}}

that will render different images according to the page I place it in.

The ability to rename an asset is the functionality that I’m up-voting. Either via an icon next to the trashcan when you hover over the image or in the right click menu of an image (or both).

I am a new user and foresee pasting in a lot of screenshots, and sometimes it’s handy to be able to name them for reference / use outside of logseq.

Nicest way with the least ‘effort’ is to make an “assets” foljder (kind of) that is visible in the left sidebar. Much like recent and favorites that show all assets and can be closed.
I right click menu to ‘manage’ those assets would be enough. On renaming ect the link should be changed to offcourse. Much like pages currently.

Pages, tags and assets all act like pages then.

Maybe just what Obsidian currently has? You can even use Obsidian to manage assets in Logseq, it will update the links and Logseq will respect them (the power of standard format like Markdown!)

Not sure what you mean with assets being treated as pages…