Assuming I want to have an org buffer in which I can preview images from url which I don't want to store on my hard drive - is there a possibility to use a solution similar to org links and display images functions?

I know I can use e.g.

(eww-browse-url "url.jpg")

but it opens an image in another buffer, which I want to avoid.

As a temporary solution I'm using a shell command (which I can put into an "clickable" elisp link in an org buffer):

(async-shell-command "wget -O /tmp/image.jpg https://url/some-name.jpg")

but to make it work I have to put another org link which will use downloaded image path (and then call org-redisplay-inline-images function):


I am looking for a oneliner solution in which I just paste the link to the image and then toggle org display images. Is there a generic Emacs way to do that?


And again we have a use-case for image data not stored on harddisk. (The other two use-cases are base64 encoded images in org buffers and displaying previews of youtube videos.)

Get org-yt and paste the following elisp code into your init-file.

After evaluating your init-file you can use links analog to the example:


(require 'org-yt)

(defun org-image-link (protocol link _description)
  "Interpret LINK as base64-encoded image data."
  (cl-assert (string-match "\\`img" protocol) nil
             "Expected protocol type starting with img")
  (let ((buf (url-retrieve-synchronously (concat (substring protocol 3) ":" link))))
    (cl-assert buf nil
               "Download of image \"%s\" failed." link)
    (with-current-buffer buf
      (goto-char (point-min))
      (re-search-forward "\r?\n\r?\n")
      (buffer-substring-no-properties (point) (point-max)))))

 :image-data-fun #'org-image-link)

 :image-data-fun #'org-image-link)
  • Thank you, @Tobias, for the link to your package. It seems to work as intended. – caseneuve Jun 27 '18 at 21:00
  • Sorry to be a critic, but I don't think assertions should be included in SE answers. Readers may not understand the meaning and proper use of assertions, and even if they do, the assertions still tend to complicate and obfuscate the answer, IMO. Rather give the straight-ahead, just-what's-needed code. As a matter of fact, I believe that the second assertion in the code above is not proper usage. Assertions are meant to be capable of being "turned off" without affecting the proper running of the code, are they not? This case requires permanent runtime error handling, I believe. – Phil Hudson Jul 4 '18 at 16:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.